Hello, thank you for the quick response.
At the moment I have to use a quite old version of Qt (5.0.2) and it seems to me that this does not support QSG_FIXED_ANIMATION_STEP, at least I cannot find that string in any source file but I do in up to date source files. I'll try to get a newer version running to check what happens in that case. Thanks again, best Regards Martin 2014-05-26 14:05 GMT+02:00 Smoke Water <qsmokeonthewa...@gmail.com>: > Hello, > > I'm facing similiar performance challanges with that "super duper high > performance" imx6 controller... > Reducing the bit depth sounds quite interesting to me. Is further > information available how to tell Qt to use for example 16 bit instead of > 32 bit for calculations? What happens with opacity/alpha information in > that case? > > The same applies to the framerate. Is there a Qt interface to reduce the > framerate? Or is it a global framebuffer setting? > It seems to me that the eglfs plugin renders as fast as possible while for > example the wayland plugin is limited to the display refresh rate. > > > Thank you very much, > Martin Ertl > > > 2014-05-23 12:00 GMT+02:00 <interest-requ...@qt-project.org>: > >> Date: Fri, 23 May 2014 09:39:56 +0000 >> From: Gunnar Sletta <gunnar.sle...@jolla.com> >> Subject: Re: [Interest] Qt5 performance on imx6 with full hd >> To: Jacob Kroon <jacob.kr...@gmail.com> >> Cc: "interest@qt-project.org" <interest@qt-project.org> >> Message-ID: <c57e3af3-0e3e-458d-b40e-768ec8ea4...@jollamobile.com> >> Content-Type: text/plain; charset="us-ascii" >> >> >> On 23 May 2014, at 10:32, Jacob Kroon <jacob.kr...@gmail.com> wrote: >> >> > Hi, >> > >> > I'm experimenting with a Qt application running on the Wandboards, >> > at full hd resolution, 1920x1080x32. I have a static background image, >> and some small animated Qml-elements on the screen. I'm not entirely >> satisfied with the resulting performance, and I think it is because of the >> background image being constantly fully redrawn in each frame. >> >> If it cannot render a single image at that resolution, then it is not a >> suitable hardware for that resolution :) >> >> If this is the case your options are to reduce the bit depth, reduce the >> resolution or reduce the framerate (such as going for 30FPS instead of >> 60FPS) >> >> Is the image alpha blended? If it is a JPEG it should be opaque, but if >> it is a PNG it will most likely have an alpha channel (even thought it >> really doesn't. I know, stupid, but that how it is). For some GPUs blending >> can add a bit of overhead, and doing it fullscreen can be what tips the >> balance. >> >> > I've experimented with >> > >> > * setClearBeforeRendering(false), since the background will be drawn >> anyway, there is no point in clearing before rendering. This seemed to have >> little impact on performance though. >> >> The effect of turning off clearing is highly hardware dependent. Some >> drivers/GPUs will benefit from not clearing as the clear is just yet >> another pass over all pixels. Others will use the clear as an indication of >> "new frame" and will have to do all manner of nasty stuff, like storing the >> depth buffer into system memory because you didn't clear it before the >> frame began. >> >> See the performance guidelines of your GPU for the actual recommendation >> for your chip. >> >> > >> > * Letting Qt5 render into /dev/fb1 overlay on the imx6, with no >> background image, but instead write the background image manually into >> /dev/fb0. In this way, the IPU will blend the result onto the display. This >> seemed to be even worse than letting the GPU render the background. >> > >> > Can the scenegraph be smart enough in such a way that it will only >> "clear" dirty rectangles with a user supplied background image ? Or are >> there any other tricks I am not aware of ? >> >> The default scene graph renderer renders the full screen. Doing partial >> updates requires a lot of support from the underlying drivers and hardware. >> If you really want to, you can give it a shot of course. You can copy the >> existing renderer, adapt it to expose dirty areas and make use of partial >> swap buffers extension if this is available (and the underlying display >> stack actually does propagate the sub regions all the way to the display). >> >> >> > >> > Regards Jacob >> > _______________________________________________ >> > Interest mailing list >> > Interest@qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/interest >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> >> >> >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
