[Interest] Qt5.1+, custom QQuickItem with text, not using QPainter?

[Bache-Wiig Jens]

On Feb 24, 2013, at 4:57 PM, Charley Bay <charleyb123 at gmail.com> wrote:

> I'm deriving from QQuickItem (in C++) to implement custom controls in Qt5.0.1, and I'd like to render text.
> 
> I don't want to use QQuickPaintedItem (a very simple solution)-- I understand and endorse the OpenGL API of the new QML Scene Graph, and will need many thousands of components, and don't want to rely upon QPainter.
> 
> I can wait for Qt5.1 APIs.
> 
> I assume there will be (soon) be some "factory" that would instantiate "QSGTexture" instances from text-strings, so I'd guess it's not worth me implementing such a thing (if that will soon be added to the Qt5.1 APIs)?
> 
> And, what is the expected design/approach for future Qt releases that require text-rendering in QQuickItem-derived classes?  If not the "QSGTexture-factory" that creates-from-text, would the primitive API for the QML "Text{}" component be exposed to C++ QQuickItem-derived classes?
> 
> Would it (for now) be good to have a (temporary) work-around where my C++ QQuickItem-derived class merely embeds a QML "Text{}" component until the (assumed-new-text-rendering-QSGTexture) APIs are available from C++ (and will these be Qt5.1)?
> 
> I'm just trying to understand "text" options (now and future-intended) in a world that does *not* use QPainter.
> 
> Thanks!
> 
> --charley
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


We are currently working on improving text rendering in two important ways. The underlying text backend in Qt Quick is actually based on the same QTextDocument that we are using in widgets and in 5.1 we are planning to indirectly expose that to C++. 

See https://codereview.qt-project.org/#change,48086 

In short, it means you will be able to do complex parsing on the text document such as adding syntax highlighters, code indentation and PDF export functionality. This is of course only an important first step, as in the future it will enable us to add more convenient QML API on top of this. Since the rendering is done independently, I do not think you will be needing any OpenGL specific text API, but I might be wrong.

The other significant change is that we are working on some major performance improvements as the performance currently do not scale very well to large text documents. You can track that progress here: https://codereview.qt-project.org/#change,48798

Regards,
Jens