Qt Graphics and Performance – Whats Hot and whats Not

On friday I added the following to the QPainter documentation:

    \section1 Performance

    QPainter is a rich framework that allows developers to do a great
    variety of graphical operations, such as gradients, composition
    modes and vector graphics. And QPainter can do this across a
    variety of different hardware and software stacks. Naturally the
    underlying combination of hardware and software has some
    implications for performance, and ensuring that every single
    operation is fast in combination with all the various combinations
    of composition modes, brushes, clipping, transformation, etc, is
    close to an impossible task because of the number of
    permutations. As a compromise we have selected a subset of the
    QPainter API and backends, where performance is guaranteed to be as
    good as we can sensibly get it for the given combination of
    hardware and software.

    The backends we focus on as high-performance engines are:

    \list

    \o Raster - This backend implements all rendering in pure software
    and is always used to render into QImages. For optimal performance
    only use the format types QImage::Format_ARGB32_Premultiplied,
    QImage::Format_RGB32 or QImage::Format_RGB16. Any other format,
    including QImage::Format_ARGB32, has significantly worse
    performance. This engine is also used by default on Windows and on
    QWS. It can be used as default graphics system on any
    OS/hardware/software combination by passing \c {-graphicssystem
    raster} on the command line

    \o OpenGL 2.0 (ES) - This backend is the primary backend for
    hardware accelerated graphics. It can be run on desktop machines
    and embedded devices supporting the OpenGL 2.0 or OpenGL/ES 2.0
    specification. This includes most graphics chips produced in the
    last couple of years. The engine can be enabled by using QPainter
    onto a QGLWidget or by passing \c {-graphicssystem opengl} on the
    command line when the underlying system supports it.

    \o OpenVG - This backend implements the Khronos standard for 2D
    and Vector Graphics. It is primarily for embedded devices with
    hardware support for OpenVG.  The engine can be enabled by
    passing \c {-graphicssystem openvg} on the command line when
    the underlying system supports it.

    \endlist

    These operations are:

    \list

    \o Simple transformations, meaning translation and scaling, plus
    0, 90, 180, 270 degree rotations.

    \o \c drawPixmap() in combination with simple transformations and
    opacity with non-smooth transformation mode
    (\c QPainter::SmoothPixmapTransform not enabled as a render hint).

    \o Text drawing with regular font sizes with simple
    transformations with solid colors using no or 8-bit antialiasing.

    \o Rectangle fills with solid color, two-color linear gradients
    and simple transforms.

    \o Rectangular clipping with simple transformations and intersect
    clip.

    \o Composition Modes \c QPainter::CompositionMode_Source and
    QPainter::CompositionMode_SourceOver

    \o Rounded rectangle filling using solid color and two-color
    linear gradients fills.

    \o 3x3 patched pixmaps, via qDrawBorderPixmap.

    \endlist

    This list gives an indication of which features to safely use in
    an application where performance is critical. For certain setups,
    other operations may be fast too, but before making extensive use
    of them, it is recommended to benchmark and verify them on the
    system where the software will run in the end. There are also
    cases where expensive operations are ok to use, for instance when
    the result is cached in a QPixmap.

I suspect it’s a piece of documentation many of you have been lacking for a while, and its something we should have put in a long time ago, but I can only say “sorry for not doing it sooner”. At least its getting done now. Note: Patch is not visible in public repository at the time of publishing. Should be there shortly

The urge to get these things into the docs have spun out from a number of dialogues I’ve had recently which all went pretty much like this:

• TheOtherGirlOrGuy: My application is running slow… What do I do?
• Me: What is it doing?
• TheOtherGirlOrGuy: Well, its using QGraphicsView and QPainter and is doing this and that…
• Me: That doesn’t sound too bad.
• TheOtherGirlOrGuy: And then its really slow when doing this…
• Me: Yeah… That doesn’t work very well. What you should be doing is this…
• TheOtherGirlOrGuy:Is that written down someplace? How am I suppose to know that?
• Me: Eh…

To remedy this, I’m going to put into action something I’ve had at the back of my head for a while now, a blog series on Qt Graphics and Performance. Along the way, I’ll also try to get parts of this into the documentation or into examples/demos as best practice use-cases.

I just have to point out, that this blog series is not a request for more features. It is about us sharing with you what we consider best practises and what our priorities are. Of course if you think our focus is way off, then let us know, but my primary intent with this blog series is to share some thoughts.

With the help of some of my co-workers, we plan to go through some Qt Graphics fundamentals, the “high-performance” engines, and usecases for graphicsview and widgets. If you have special usecases that you find interesting, then by all means let me know and maybe I can cover those too.

I need to add a small comment to the “drawText” case. It is currently not super optimal, because we have to do layout on the text for each time you call it. Because there is no “handle” in the function we don’t have the ability to cache the layout either. If we started caching based on a qHash of all the strings that were passed to drawText() then we end up caching a lot of single-shot text drawing… The option that we provide today to work around this is to use a QTextLayout with caching enabled, which is memory-wise quite hungry… I think in the range of 100-300 bytes pr character! So as an alternative, we are working on an API for static text which encapsulates the layout work with very little memory overhead. Its currently called QStaticText and we’re aiming for it to go into 4.7. Once it is in place, we’ll update the drawText comment in the performance documentation to be for these static texts…

As time permits we plan to push out blogs on the following topics:

• An overview of the various components involved
• The raster paint engine in detail
• The OpenGL paint engine in detail
• The OpenVG paint engine in detail
• QGraphicsView optimization flags and cache modes

No related posts.