On Wed, Mar 3, 2010 at 11:05 PM, Zack Rusin <[email protected]> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
