Important: Please read the Qt Code of Conduct -

Which renderer is utilized?

  • I experience extreme long render times of up to 3 seconds with the following setup:
    Atom N250+HT, Intel 45GSE, 2GB RAM under linux kernel 3.15.

    A scene is rendered in 1920x1080 with five gridviews displaying about 300 delegates visible at once.
    as soon as any content of any item is changed, it takes up to 3 seconds to update.
    The QML code is very simple and hierarchically organized, so I wonder if the scenegraph has problems to render efficiently. If nothing is changed, 'top' reports less than 3% CPU usage.
    QSG_INFO=1 tells me "GL_RENDERER: Mesa DRI Intel(R) 945GME x86/MMX/SSE2".
    QSG_RENDER_TIMING says: "- Breakdown of frame time; sync: 0 ms render: 2702 ms swap: 0 ms total: 2703 ms time since last frame: 2760 ms".

    The hardware is not very fast, but that does not explain the long rendering time.

    EDIT: Alright, the driver needs OpenGL 2.0(+) support, I will update this and check again :-)

    EDIT: Alright again, looks like the GPU (driver) does and will not support OpenGL 2.0, so I know that there is no chance to get this fixed.

  • Not sure I understand the problem..

    If the driver doesn't support OpenGL 2.0, then it will either emulate in software using swrast or llvmpipe which should yield very high CPU load or it should show nothing at all.

    Are delegates clipped? Does QSG_VISUALIZE=batches indicate that things are being batched properly? If you have 300 delegates which each go to their own batch, then high render times are to be expected.

  • LIBGL_ALWAYS_SOFTWARE=1 results in a rendering time just as long, so most probably software rendering was already used before due to lacking driver capabilities.
    QSG_VISUALIZE=batches shows, that all delegates within one view have the same color, so they are within the same batch(?).
    QSG_VISUALIZE=overdraw shows practically no multiply drawn areas.

    There is a trick to get QML+ HW-OpenGL (partially) running on my Chipset using the tool "driconf", but the target has a very lean firmware-like linux environment with no python installed, which is needed by "driconf".
    The trick is described "here":

    So, if someone can tell me how to enable/disable driver functions without "driconf", I might be saved :-)

Log in to reply