> I find frame rate issues when using: > > * opacity that is not equal to zero or one > * "rounded rectangles" a.k.a Rectangles with specified radius property > * clip property (sometimes)
The SGX does not do GL_BLEND very well. In fact it does it quite badly, so opacity other than 0 an 1 should be avoided at all costs on this hardware. Qt Quick will potentially make this worse when antialiasing is used on items as the antialiasing is implemented by default by using vertex opacity and the entire primitive becomes blended, regardless of its shape. 5.2 makes it possible to prefer multisample antialiasing over vertex antialiasing by adding QSurfaceFormat::setSamples() to QQuickWindow::requestedFormat(). QSurfaceFormat format = window.requestedFormat(); format.setSamples(4); window.setFormat(format); This will cause both images and rectangles to use MSAA for antialiasing which means that the primitives themselves are fully opaque. With the new renderer this is even better as opaque primitives can be freely batched with very little overhead. The same can be acheived in Qt 5.1 by using a customcontext from https://github.com/qtproject/playground-scenegraph/tree/master/customcontext and configuring it with > qmake -config msaa That leaves image art. It generally has semi transparent areas and opaque areas and for hardware that doesn't do blending one ideally wants to split the image into its opaque and translucent parts. I started playing around with this in the spring here: https://github.com/qtproject/playground-scenegraph/tree/master/shapes It is working but not product quality at this point, but it gives an idea about what can be done. > The problem is worse especially at higher resolution displays > such as 1280x800. Evidently, TI recommends to only drive a > somewhat smaller display (800x600 or less) so these frame > rate problems aren't encountered as easily. The BeagleBoard-xM hardware is not spec'ed to drive a resolution that high. When it fails to do so, that is hardly the blame of Qt :) > I wrote a simple 2D Knob widget which has a mouse area, > a little Javascript, and should just rotate a single PNG file > on the GPU. It uses 20-45% of the Beagle CPU during > knob dragging (!), according to Linux "top" command. I believe the device supports CPU frequency scaling. Is this what you are seeing perhaps? cheers, Gunnar ________________________________________ Fra: interest-bounces+gunnar.sletta=digia....@qt-project.org [interest-bounces+gunnar.sletta=digia....@qt-project.org] på vegne av VStevenP [vstevenpa...@yahoo.com] Sendt: 19. november 2013 21:07 To: Ola Røer Thorsen; interest@qt-project.org Emne: Re: [Interest] Tearing in Quick2 flickable-based items with clipping enabled Hi Ola, Maybe you found this page? http://processors.wiki.ti.com/index.php/SGXDbg#SGX_Driver_Failure_Modes_.28Run_time.29 My research is also showing Qt performance is lacking on BeagleBoard-xM hardware, both in fps and cpu usage. (BTW, this is a hardware that has the PowerVR SGX 530 GPU.) Maybe now that BB-xM is officially supported for Boot to Qt EE, we can get some good feedback from Qt Project team members about getting better performance of Qt5 on BB-xM. I find frame rate issues when using: * opacity that is not equal to zero or one * "rounded rectangles" a.k.a Rectangles with specified radius property * clip property (sometimes) The problem is worse especially at higher resolution displays such as 1280x800. Evidently, TI recommends to only drive a somewhat smaller display (800x600 or less) so these frame rate problems aren't encountered as easily. (BTW, I use Qt's own FpsItem.qml component from the Qt Cinematic Experience demo to test frame rate. I control it's visibility dynamically because that component uses 25%+ of Beagle CPU alone, and I don't always want it using so much CPU when I'm trying to analyze other widgets CPU usage). What is bugging me just as much as the FPS issues (which I have worked around by limiting use of opacity, rounded rectangles, and judicious use of clipping) is CPU USAGE of simple widgets. I wrote a simple 2D Knob widget which has a mouse area, a little Javascript, and should just rotate a single PNG file on the GPU. It uses 20-45% of the Beagle CPU during knob dragging (!), according to Linux "top" command. This seems too high for such a simple widget. I haven't done detailed profiling of the widget using QML Profiler (External) yet, but I wonder if you have observed the hoggish CPU % usage values during widget edits, and found any reason why the simplest widgets can eat up half the CPU cycles during editing. Maybe it's some other OS configuration settings which are having some effect, but I had certainly hoped simple widgets would use much less CPU by default. It would be nice if Qt had a white paper which could explain how to maximize performance on BB-xM, or if one of their more experienced team members who are familiar with BB-xM could give some guidance for lessing CPU usage numbers of simple QtQuick2 widgets. - VStevenP -------------------------------------------- On Thu, 11/14/13, Ola Røer Thorsen <o...@silentwings.no> wrote: Subject: Re: [Interest] Tearing in Quick2 flickable-based items with clipping enabled To: "Sletta Gunnar" <gunnar.sle...@digia.com> Cc: "interest@qt-project.org" <interest@qt-project.org> Date: Thursday, November 14, 2013, 5:24 AM Hi again, digging further into this reveals some issues with the PowerVR SGX530 (Omap3) when using the flip mode. So it's not Qt. Sorry for the noise. Seems like it only happens at 60Hz. Will there be an option in 5.2 to set the swap interval, or did it end up in 5.3? I'd probably go for a steady 30Hz instead of a 30-60 mix with the occasional tearing. Cheers,Ola 2013/11/13 Ola Røer Thorsen <o...@silentwings.no> Hi Gunnar, I'll see if I can create a small example that reproduces it. Cheers,Ola 2013/11/13 Sletta Gunnar <gunnar.sle...@digia.com> If this consistently reproducible across desktop and device, then I would appreciate a bugreport with an example that reproduces it. It is not a known issue to me at least. (bugreports.qt-project.org) Clipping is implemented using scissor or stencil depending on the complexity of the mask, no intermediate texture is involved. cheers, Gunnar Fra: interest-bounces+gunnar.sletta=digia....@qt-project.org [interest-bounces+gunnar.sletta=digia....@qt-project.org] på vegne av Ola Røer Thorsen [o...@silentwings.no] Sendt: 13. november 2013 15:29 To: interest@qt-project.org Emne: [Interest] Tearing in Quick2 flickable-based items with clipping enabled Hi all, I'm seeing tearing-effects when scrolling in ListView and other items based on Flickable when clipping is enabled. This is running on both a Linux desktop as well as an embedded Linux device (eglfs). The Qt version is 5.1.1. The systems are running with vsync enabled and double-buffering. There is no tearing in any other items except the ones with clipping enabled. Tearing is especially noticeable on the embedded device. The GPU is a PowerVR SGX chip which is tile-based, so the tearing "lines" are actually vertical. Also the framerate is mostly somewhere between 30-60. Tearing appears maybe 20% of the time spent scrolling. I'm wondering if the core issue is this: I assume clipping is implemented as rendering the item into a temporary texture, and the clipped area is of this is finally rendered to the screen buffer. This temporary texture is not double-buffered. This means it would be possible that the render pipeline starts writing into a texture (next frame) that is being drawing into the screen buffer (current frame). Any thoughts? The tearing is really bad sometimes, and I don't really have the option of disabling clipping either. Cheers, Ola -----Inline Attachment Follows----- _______________________________________________ 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
