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

[VStevenP]

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