[webkit-qt] QImage vs QPixmap

[Zack Rusin]

On Wednesday 03 March 2010 15:31:14 Antti Koivisto wrote:
> On Wed, Mar 3, 2010 at 9:53 PM, Zack Rusin <zack at kde.org> wrote:
> > On Wednesday 03 March 2010 14:35:03 Antti Koivisto wrote:
> > It was really the GL pipeline we were thinking about and I think that is
> > still very valid.
> 
> I understand that there is a texture cache for QImages too when
> rendering to OpenGL context. Is there still real performance
> difference between the two? (besides the more general point of whether
> trying to render a web page using OpenGL is sensible in the first
> place)

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

> > Software renders are a great answer to the question of quality, rather
> > than performance. It's especially the case for mobile devices where even
> > though
> 
> We don't want that kind of trade-off. Modern mobile browsers deliver
> both speed and high quality rendering.

Note though that this is the case right now!  

Assuming some optimizations to the GL engine (texture atlases, usage of 
ARB_blend_func_extended for subpixel font hinting, and addition of 
QPixmap::update) would blow everything else out of the water, but as it stands 
people can easily set graphics system in their apps to "raster" in which case 
all those QPixmap's will automatically become QImage's, others can set the 
graphics system to GL in which case all those QPixmap's become texture, others 
can set it to VG in which case they become VGImage's, etc. 
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.

> > GPU's are usually slower than the CPU's they use a very small fraction of
> > the power that it would take to rasterize something on the CPU. So it's a
> 
> This is a very board statement. 

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.

> GPUs are very good in some things and bad in others. 
> I don't think rasterizing a typical web page is in the first category. 
> I have yet to see anything that would convince me otherwise.

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.

z