We're talking about HTML5 canvas here... In canvas everything is imperative, in the UI thread anyway, needs to be extremely fast sometimes, animated... Forcing all that to be rasterized doesn't sound right and will result in slow canvas, which we already have today without doing any work :)
Note that with the DirectFB engine we accelerate everything and webkit is much faster. That's because the pixmap implementation is straightforward and DirectFB manages the off-screen buffers correctly in the backend. Forcing all of the drawing to go through a QImage in DirectFB would kill our offering on that type of hardware. Please let's not do that. Knowing our pixmaps and webkit pretty well, I'd say that the problem needs to be fixed inside the graphics system (making the video-memory / system memory heuristic cache in there) and not in QtWebkit. >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On Behalf Of ext >Ariya Hidayat >Sent: Friday, February 05, 2010 8:35 AM >To: [email protected] >Subject: Re: [webkit-qt] GraphicsContext and Canvas > >Seems that my little refactoring proposal opens a (bigger) can >of worms :) > >So how about extending it to "Let's deprecate the use of >QPixmap inside QtWebKit". Any objections to that? > >Note that in Chromium, only software rasterizer is used because of the >(security) design: they don't allow any external influence (GPU, X11, >etc) for doing the painting. Yet, if you run the Monster Demo >(or any other Chrome Experiments) in Chromium, it's blazing >fast. So we can argue that using QImage *only* does not >necessarily mean a performance impact. > >In addition, for animation and transition, we already have >accelerated composition support with potential hardware >acceleration. That's what people should use if they want the >fancy bling-bling. > >Comments? >_______________________________________________ >webkit-qt mailing list >[email protected] >http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt > _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
