[Qt-qml] Plead for the cached Text

[joona.t.petrell at nokia.com]

Hi Juha,

We haven't done OpenVG specific test on non-cached vs. cached text, but I run QML code on Symbian^3 weekly, and haven't been aware or noticed issues you are describing, in fact on the contrary I thought the text drawing changes actually speeded up the frame rates on Symbian. The caching was originally disabled as the new text drawing routines were supposedly as fast or even faster than the caching approach, and yeah used less GPU memory.

Could you send me your code so we can test what is wrong and whether the performance issue can be reproduced on the newer version of QtQuick?

> Would it be possible to take the middle way and make the caching of
the rendered text optional (preferably so that you explicitly opt
out)?

You can enable text caching by executing following line on the C++ side of your application.

qputenv("QML_ENABLE_TEXT_IMAGE_CACHE", "true");

Cheers,

Joona

-----Original Message-----
From: qt-qml-bounces+joona.t.petrell=nokia.com at qt.nokia.com [mailto:qt-qml-bounces+joona.t.petrell=nokia.com at qt.nokia.com] On Behalf Of ext Juha Turunen
Sent: Friday, January 21, 2011 11:04 AM
To: qt-qml at trolltech.com
Subject: [Qt-qml] Plead for the cached Text

Hi all,

(If this sounds like a rant, it's really not.)

after months of waiting and painful infix building we finally got
QtSDK TP 1.1 for Symbian. Yay, what a day of joy! I quickly (no pun
intended) installed the new runtime to my test devices, started a test
app and suddenly didn't feel so happy anymore. The reason was that the
text rendering had taken a pretty bad hit.

I'm speculating that the reason for this is the fix to:
http://bugreports.qt.nokia.com/browse/QTBUG-14050 (TL;DR: Text element
used to draw itself to a pixmap and then just draw the pixmap when
animated)

I understand completely the reasoning for the fix (I even reported the
same issue when I noticed that big lumps of text don't work at all,
but failed to see the implications of the change), but I don't think
this cuts it either. My test app which has about two screenful of
items (on a 640*360 screen) used to run really nice on the current
Symbian^3 hardware, but now the wow effect is pretty much gone,
because the scrolling stutters. It's not just the drop in the
framerate, but the real issue is that the framerate is inconsistent
and that looks horrible. I guess this is because on different frames
different amount of text gets drawn (varying line lengths, gaps
between the items containing the text, etc)? On top of that applying
transformations on Text items kills the performance completely and the
framerate is something like 5fps (it used to be 30fps+ and kept
getting better when less and less pixels were drawn by the GPU).

I can live without transformations, but not without smooth scrolling.
I know GPU memory is a scarce resource (~20MB left after boot on the
current S^3 hardware), but noone (at least of the consumers who pay
money for the stuff we make) really cares about how many apps you can
run at a time if that single one isn't meeting the expectations set by
the competition (iOS).

Would it be possible to take the middle way and make the caching of
the rendered text optional (preferably so that you explicitly opt
out)? That way we could have both faster and more stable framerates
with caching (when it makes sense) and bigger bodies of text with no
cache (could be forced to no-cache if dimensions of the painted area
reach some limit). If the caching was a property of Text it could be
used to also purge the cached text when it's not needed. Re-rendering
it won't take that long anyway when it's needed again. In my test app
the two screen of items the actual text occupies the area of maybe
50%-60% of those two screens. That totals about ~1MB of GPU memory -
5% of the amount available if nobody else is hogging it. Multiples of
that can easily be spent on loading multiple background images, etc.
In the next iteration of Symbian hardware there will still probably be
a separate GPU (to keep the door open for chipsets without an
integrated GPU) with no UMA, but likely a double the amount of GPU
memory. So it might not even be that big problem in 2012 - stuttering
scrolling though is a problem in 2011.

I hope this issue will get some attention and possibly a fix before
QtQuick goes big and OviStore deployable. I can of course implement my
own Text item that behaves exactly like I want it to, but it would be
really sad to see everyone (who is even aware of the issue) to jump
through hoops to get where we should already be in this market.

In case the problem is somewhere else and already fixed: "I'll get me coat" :)

Juha
_______________________________________________
Qt-qml mailing list
Qt-qml at qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-qml