[Interest] Qt5 performance on imx6 with full hd

[Martin Ertl]

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 <qsmokeonthewater at 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-request at qt-project.org>:
>
>> Date: Fri, 23 May 2014 09:39:56 +0000
>> From: Gunnar Sletta <gunnar.sletta at jolla.com>
>> Subject: Re: [Interest] Qt5 performance on imx6 with full hd
>> To: Jacob Kroon <jacob.kroon at gmail.com>
>> Cc: "interest at qt-project.org" <interest at qt-project.org>
>> Message-ID: <C57E3AF3-0E3E-458D-B40E-768EC8EA446A at jollamobile.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>> On 23 May 2014, at 10:32, Jacob Kroon <jacob.kroon at 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 at qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140527/460b86f7/attachment.html>