[webkit-qt] QImage vs QPixmap

[Antti Koivisto]

On Wed, Mar 3, 2010 at 11:05 PM, Zack Rusin <zack at kde.org> wrote:
> Currently the only one is that QImage's will be uploaded on the first
> rendering, while QPixmap's on construction.
> In an ideal world, where we had something like QPixmap::update() call I
> mentioned in the first email the difference would be that one could update the
> data in QPixmap without recreating surfaces while the same wouldn't be easily
> possible for QImage's (QImage's would have to start tracking damage regions to
> themselves or such to let paint-engine update the cached surfaces and then the
> id's of QImage's couldn't change on updates so that the right texture could
> still be found in the cache... it would be very messy).

It sounds to me like the original performance reasons for using
QPixmaps over QImages don't apply anymore?

> If we were to switch to a QImage that would no longer be possible. QPixmap can
> easily globally become a QImage but QImage can't easily become a QPixmap.

If QImages get cached as textures in GL context, isn't that
essentially the same thing?

> Well, no it's not. "GPU's are better" is a broad statement, mobile gpu's using
> less power than rasterization on a cpu is simply a statement.

Sorry, I actually misread what you said here. I thought your original
top argument was about QPixmaps being faster that QImages.

I think that currently rendering speed is the main concern, not he
power use. In any case, painting is only a portion of the overall
power consumption. Using a tiled backing store minimizes the need to
actually draw from the WebKit render tree for things like scrolling.
Tiles make really nice objects to be turned into textures and painted
using GPU.

The main reasons I'd prefer using QImages everywhere are

1) QImage is less confusing abstraction than the QPixmap. Since nature
of QPixmap depends completely on context, it is hard to explain,
understand or optimize for. It's performance characteristics are
opaque (QImage texture cache unfortunately muddles it too). I'd prefer
to have APIs that don't do magical things unless specifically asked
for, especially for something as low level as a bitmap image.
2) QImage is usable from any thread. This is required for secondary
thread painting. Patching QPixmap to be usable from any thread would
make it even more confusing (it would be safe to use outside the main
thread on some contexts, not on others)
3) Fast updates etc.mentioned by others

> Web pages hardly rasterize anything. They largely render text and images, and
> GPUs are highly optimized for those (for text obviously only the more recent
> ones with dual source blending). Canvas does some rasterization but its usage
> is still fairly elementary and the paths one needs to rasterize are usually
> very simply.

I meant "rasterizing" as in turning the web page into screen pixels. I
suppose some other term would be preferred. :)


   antti

>
> z
>