[Interest] Qt5 performance on imx6 with full hd

[Smoke Water]

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/20140526/fd81d865/attachment.html>