QPixmap vs. QImage
Zack Rusin
zack at kde.org
Wed Nov 11 19:30:50 CET 2009
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
More information about the Plasma-devel
mailing list