On Feb 24, 2013, at 4:57 PM, Charley Bay <charleyb...@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@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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
