[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