On 26 May 2014, at 14:05, Smoke Water <qsmokeonthewa...@gmail.com> wrote:
> 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? You can request different GL surface formats through QSurfaceFormat in Qt, but what the GL context actually takes into use is decided by the platform plugin. What is used in the rest of the display stack is out of Qt's control. > > 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. We generally request a vsynced opengl context and then render as fast as possible (being throttled, for instance by eglSwapBuffer). You can control this through public Qt API in 5.3 using QSurfaceFormat::setSwapInterval(), but the platform plugin is free to ignore this hint. Another thing that might be relevant to check is if the problem is that of un-even animation steps. Does setting QSG_FIXED_ANIMATION_STEP=1 in the environment have an impact? cheers, Gunnar > > > 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
