[webkit-qt] QImage vs QPixmap

Holger Freyther zecke at selfish.org
Wed Mar 3 13:56:23 PST 2010


On Wednesday 03 March 2010 19:50:59 Zack Rusin wrote:
> Hey,

> 1) QtWebKit used to use QImage's. Switching to QPixmap's was the first
> "optimization" we've ever done for it. In the initial port everything used
> QImage's and it was simply awfully slow, which is why we almost immediately
> switched over to QPixmap's.

Unless you are on X11 with XRender where you have nice roundtrips during 
painting because we need to fallback to the raster engine. One of the problems 
with the nice abstraction of QPainter,QImage and QPixmap is that you will 
never know if your painting will be fast and accelerated, or you will have to 
copy data back and forth...



> 3) Yongjun said that "both Qimage and Qpixmap has to be kept in RAM for
> short period, which increases the peak memory consumption too." which is
> true but it's worth noting that it's not an argument against QPixmap but
> rather pro it. We need 2x the memory for QImage than what we need for
> QPixmap. QImage needs the CPU mem copy (what we usually understand as a
> QImage) and the GPU mem copy that we have to upload to actually render it,
> whereas the QPixmap needs only the latter. The only case where this
> differs is when the entire qwindowsurface is a qimage in which case only
> the qwindowsurface has 2x the memory but everything else is ok.

Just to toss more numbers to the game (I recently learned counting in chinese 
and want to improve my number skills... yeah yeah not so recently).

Going from an indexed GIF to XImage with the current XRender backend in Qt 
will make our peak four (si) times instead of two (er)... but  this was mainly 
an excercise for my chinese skills.. so please ignore.




> 5) Probably something along the lines of "QPixmap::update(int x,
> int y, int w, int h, const uchar *data, uint len, QImage::Format format)"
> or such. This way we could easily stream data into QPixmap's without
> resorting to usage of QImage in those paths. Of course that involves a
> nice chunk of code to be added to Qt...


Amen, this way we could do a a nice putPixel of canvas while still having it 
in a QPIxmap.


My personal issue with QPixmap is more anong the lines that only the backend 
can know if I can accelerate a certain operation or not and that an app author 
can only do guess work unless we start targeting a specific engine instead of 
going through the QPainter interface..


greetings from freezing cold iceland
	z.


More information about the webkit-qt mailing list