Previously (I think pre-5.2) this env variable name started with QML instead of QSG, so try: QML_FIXED_ANIMATION_STEP
BR, Filip Piechocki On Tue, May 27, 2014 at 10:07 AM, Martin Ertl <qsmokeonthewa...@gmail.com>wrote: > 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 > >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
