[Interest] Tearing in Quick2 flickable-based items with clipping enabled
Ola Røer Thorsen
ola at silentwings.no
Fri Nov 22 15:17:42 CET 2013
Thanks for the feedback both of you!
VStevenP, yes I've looked at the TI wiki regarding failure modes and
whatnot, and tried setting the paramBufferSize and such. Doesn't seem have
any effect on the tearing. I think they might have some race condition in
the gpu driver or something,
My application is running at 800x480. I knew the SGX wasn't very powerful
before starting coding so I didn't expect too much. Therefore I've actually
been rather happy with the general results. I've done things like
- Make sure to set the background color on the QuickView and NOT fill the
whole screen with a background rectangle the way most example snippets do
- Avoid animating movement of large Items (looks jerky anyway), I just fade
opacity in/out.
- At least in 5.1.1 opacity = 0 is slower than visible = false so I make
sure to set visible = false as often as possible (documentation examples
often say it's enough to do opacity=0)
- Try to avoid clip = true, and never use smooth = true
- Keep javascript logic to an absolute minimum, move as much as possible to
c++ (the arm core isn't the quickest one either).
- Use dynamic creation of larger gui modules on demand, to limit the amount
of active bindings on things that aren't on screen. The annoying bit here
is the waiting pause when the new QML items are compiled on the fly. You
don't notice that on the Desktop, but you sure do on ARM.
Compared with my previous application based on Qt4's widgets that I now
have replaced, the new one uses just a third of the cpu load, with much
smoother and more complex things happening on the screen.
I hope to try 5.2 as soon as possible.
Cheers,
Ola
2013/11/20 VStevenP <vstevenpavao at yahoo.com>
> 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
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131122/baaa8074/attachment.html>
More information about the Interest
mailing list