[webkit-qt] QImage vs QPixmap

[noam.rosenthal at nokia.com]

API-wise, can we use a QPixmap with forced QRasterPixmapData in key places (e.g. images that are loaded from the network; canvas buffer) instead of an explicit QImage everywhere? 
This would 

(a) reduce 80% of the code needed for the change without changing its functionality 
(b) allow us to contain the optimization in one place instead of affect everything
(c) not completely break my new pixmap stuff in the QtWebkit bridge
(d) interact much better with AC
(e) allow the change to be easily modified with a compile flag

Though this might require to hack something as the Qt API because QRasterPixmapData is private :(

I do believe, after researching it lately, that canvas should use software rasterization, and that HW acceleration should be reserved to AC, including WebGL/video/plugins when those can be composited. The kind of things people do with canvas are just too complicated for QPainter based HW acceleration - usually include a lot of complex transformations, polygons, raster-effects and other things that would normally fall back to raster. Accelerable canvas operations are better done with CSS if it's simple 2D UI stuff, or with WebGL if it's complicated (where you can upload shaders and optimize in application code).


>-----Original Message-----
>From: webkit-qt-bounces at lists.webkit.org 
>[mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of ext 
>Antti Koivisto
>Sent: Thursday, March 04, 2010 6:24 AM
>To: Zack Rusin
>Cc: webkit-qt at lists.webkit.org
>Subject: Re: [webkit-qt] QImage vs QPixmap
>
>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
>>
>_______________________________________________
>webkit-qt mailing list
>webkit-qt at lists.webkit.org
>http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>