[webkit-qt] QImage vs QPixmap

[Zack Rusin]

On Wednesday 03 March 2010 17:23:50 Antti Koivisto wrote:
> 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?

Well, not quite. The purely performance ones have certainly been reduced but:
1) Upload in the paint event vs at creation time is not ideal. Really anything 
that uploads in the paint event is just no ideal but in the global scope of 
things when only the initial frames takes 10x longer than all the subsequent 
ones, it's not that bad.

2) it works only for paint engines that actually do the caching (qimage id 
versus native surface format). X11 engine doesn't do that caching and it's 
still default on Linux. I have a feeling KDE folks will be violently opposed 
to making QtWebKit significantly slower :)

3) it's 2x memory usage vs qpixmap. 

> > 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?

Similar, not the same. QImage doesn't become a texture, it's still a QImage it 
just happens to have another surface associated with it in a different part of 
Qt. So while QPixmap can be a QImage, QImage can be a QImage plus something 
else.
 
> 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.

Yeah.

> 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.

To be honest I don't think that's possible on Qt right now :) The QPixmap's 
definition of "native format to the graphics system used" is still a lot 
clearer to me than QImage which is "QImage, unless the paint-engine does 
caching, like the GL engine, in which case it's a QImage plus the native 
format to the graphics system, stored somewhere else".

> 2) QImage is usable from any thread. This is required for secondary
> thread painting. 

Yea, that's a nice feature of QImage's.

> 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)

I'm not sure I understand, in what context's wouldn't it be ok? Qt simply 
needs to lift the requirement to not use QPixmap outside the gui thread. The 
main reason for this was the X11 engine which uses Xlib which is very quirky 
when it comes to threaded usage. X11 engine should be ported to Xcb anyway, 
which would basically also fix the threaded issue. GL itself has been thread 
safe pretty much always, so the GL engine would be a lot simpler. The threaded 
painting to QPixmap was one of the items on the roadmap when I was still at 
tt, so I'd certainly hope it hasn't been removed.

> 3) Fast updates etc.mentioned by others

Yea. Of course this could be fixed by that QPixmap::update thing I mentioned, 
but yea, right now QPixmap's aren't "ideal" for incremental loading of images.

I don't know, I simply don't see QImage's being a viable choice as long as the 
X11 works the way it works and is the default on GNU/Linux. Of course the 
performance characteristics of QtWebKit (especially with the tiles 
optimization you mentioned) probably changed a lot since I've done the first 
port to QPixmap's and ultimate if a benchmark would show QImage's to be faster 
than what we have now I certainly wouldn't argue against it (I'd just be very 
surprised :) ).

z