[Interest] Tearing in Quick2 flickable-based items with clipping enabled

Wed Nov 20 07:58:35 CET 2013

> 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.com at qt-project.org [interest-bounces+gunnar.sletta=digia.com at qt-project.org] på vegne av VStevenP [vstevenpavao at yahoo.com]
Sendt: 19. november 2013 21:07
To: Ola Røer Thorsen; interest at 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 <ola at silentwings.no> wrote:

 Subject: Re: [Interest] Tearing in Quick2 flickable-based items with clipping enabled
 To: "Sletta Gunnar" <Gunnar.Sletta at digia.com>
 Cc: "interest at qt-project.org" <interest at 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 <ola at 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.Sletta at 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.com at qt-project.org
 [interest-bounces+gunnar.sletta=digia.com at qt-project.org]
 på vegne av Ola Røer Thorsen [ola at silentwings.no]

 Sendt: 13. november 2013 15:29

 To: interest at 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 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