[Interest] Qt5 performance on imx6 with full hd

[Filip Piechocki]

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 <qsmokeonthewater at 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 <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
>>>
>>>
>>>
>>
>
> _______________________________________________
> 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/d97f3df2/attachment.html>