QPixmap vs. QImage

[Zack Rusin]

On Wednesday 11 November 2009 11:00:21 Sebastian Kügler wrote:
> Hey fellow plasmoids,
> 
> I've been wondering for a while now what I should use for rendering
>  pixmap-based imaged onto Plasma running on X, QPixmap or QImage. The
>  usecase I'm coming across regularly is that I paint an icon, and something
>  on top of that. Possibly animated so we sometimes are rendering a few
>  frames per second.
> 
> To give a usecase, last summer, I've moved the picture frame applet from
>  using QImage all over to QPixmaps. Resizing (which involved often resizing
>  the image shown from original size down to displayed size) seems to be
>  smoother and less CPU-heavy with these changes. One observation I made was
>  that t
> The resizing is done by drawing a larger QPixmap into a smaller rect, as
>  advised on techbase (
>  http://techbase.kde.org/Development/Tutorials/Graphics/Performance ).
> 
> So ...
> 
> (1) what's faster?
> (2) what saves my battery? (probably related to (1))
> (3) what's most memory-efficient?
> (4) ... what should I use?
> 
> My assumptions (I take it, they're likely over-generalized and possibly
>  wrong, that's why I'm writing them down -- corrected wrong assumptions are
>  better than just wrong assumptions).
> 
> - QPixmap is managed in video memory, what you're dealing with is more or
>  less a reference to an X pixmap. Painting on a QPixmap means, if done
>  well, that it's done on the graphicscard. This seems more power-efficient,
>  and faster since we can use acceleration of the GPU.
> 
> - Painting QImages with the raster graphicssystem seems a lot faster
>  because the raster engine is more optimized and doesn't depend heavily on
>  good quality drivers. Many people report smoother rendering when using the
>  raster graphicssystem, compared with the default, "image" graphicssystem.
>  It does, however, everything on the CPU, which is less ideal for such
>  tasks.
> 
> I guess a whole lot of the answer depends on driver quality, so there's
>  probably not one clear, right answer. Or maybe the real question seems to
>  be: are we writing code for the ideal system, with well working drivers,
>  or are we writing code that will run well on what we have now?

Oh, how I wish I could just give you "the Dirk" (for those less fluent in KDE 
social scene "The Dirk" is a one sentence answer that gives you the definite 
answer to the question) but I can't. It's all shades of gray. All the shades 
look good in some circumstances. 

In my experience with graphics when you're making a passive/ahead of time 
decision to go with one particular shade of gray you're putting yourself in a 
defensive position because there will be cases where it will not work too well 
and militant users/clients will come after you.

The graphics guy in me goes "KDE should use only OpenGL for graphics" 
(hopefully soon we'll have software OpenGL working reasonably fast
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/llvmpipe/README 
), but a desktop user in me weeps when he hears this.

Pragmatically speaking KDE should move away from making a passive/ahead of 
time decision about how graphics should work to active/real time one.

So when we start a desktop for the first time we should run a quick 
representatives benchmark that will tell us whether GL is fast enough, whether 
Xrender is fast enough or whether we should use raster. Encode that result in 
a cpu/gpu/driver version key and store it (rerun if the key changes). 
Depending on the result we should store what graphicssystem Qt should be using 
globally. Then always use QPixmap. Qt, depending on which graphicssystem is 
used,, would do the right thing about it. 
Think http://i.i.com.com/cnwk.1d/i/tr/tpg/VISTA01.JPG , we don't have to be 
necessarily giving people numbers but we should be able to figure out how KDE 
should run. All in the spirit of making sure the gray we pick is the best gray 
we can possibly select in the particular case and to make sure the KDE 
experience on the given system is best it possibly could be.

If we're down with that I could probably prepare the benchmark/key code for 
you.

z