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

VStevenP vstevenpavao at yahoo.com
Wed Nov 20 18:28:45 CET 2013


Hi Gunnar -

Thanks for these performance improvement ideas.

I write QtQuick2 apps.  I'll see if I can use requestedFormat().  (I know how to write widgets in C++ and make them available in QML.)

I rechecked my emails, and it was a Digia rep who made the comment about 800x600:

"The SGX chip on the BeagleBoard is not really capable of running any advanced graphics at a high display resolution, which is why we have set it to 800x600 by default. This is the highest resolution with which we are comfortable performance wise."

That said, you are correct - it's not Qt's fault for SGX GPU shortcomings.

Yes, DM3730 on BB-xM supports CPU frequency scaling.  I don't think I'm using frequency scaling in my current configuration, because I am using Angstrom 2011.03 from Narcissus Image builder.  I'll get a new package from Narcissus which contains cpufrequtils and investigate.  I really hope I can document that CPU usage of simple custom QtQuick2-based widgets is reasonable on DM3730/BB-xM.

- VStevenP

--------------------------------------------
On Wed, 11/20/13, Sletta Gunnar <Gunnar.Sletta at digia.com> wrote:

 Subject: SV: [Interest] Tearing in Quick2 flickable-based items with clipping enabled
 To: "vstevenpavao at yahoo.com" <vstevenpavao at yahoo.com>, "Ola Røer Thorsen" <ola at silentwings.no>, "interest at qt-project.org" <interest at qt-project.org>
 Date: Wednesday, November 20, 2013, 1:58 AM
 
 > 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





More information about the Interest mailing list