[webkit-qt] GraphicsContext and Canvas

[Lars Knoll]

Hi Ariya,

great you're looking into this. 

One thing worth considering is IMO to only use a QImage to render the canvas 
content into, and avoid any caching/conversion magic between images and 
pixmaps. We don't get any HW acceleration for drawing with this, but it might 
still be faster and easier than doing possible conversions back and forth.

Cheers,
Lars

On Thursday 04 February 2010 07:56:50 am Rosenthal Noam (Nokia-D-
Qt/RedwoodCity) wrote:
> Hi Ariya
> First of all, awesome that you're looking into this! I was praying for this
>  moment :) Second - our canvas implementation is not just slow, it's also
>  inaccurate. See https://bugs.webkit.org/show_bug.cgi?id=32405.
> 
> About that internal buffer - how would that work with HW acceleration and
>  memory consumption, also considering  that GraphicsLayer has an additional
>  intermediate buffer in the form of graphics-view cache?
> 
> Cheers
> No'am
> 
> 
> 
> ________________________________________
> From: webkit-qt-bounces at lists.webkit.org
>  [webkit-qt-bounces at lists.webkit.org] On Behalf Of ext Ariya Hidayat
>  [ariya.hidayat at gmail.com] Sent: Wednesday, February 03, 2010 10:43 PM
> To: webkit-qt at lists.webkit.org
> Subject: [webkit-qt] GraphicsContext and Canvas
> 
> Hello good people,
> 
> Currently Canvas is not performing very well, see
> https://bugs.webkit.org/show_bug.cgi?id=32530 for the details of one
> of the problems. I have a patch for that (attached in the bug, please
> review!) by introducing BufferedImage, but that is just a stop-gap
> measure. This is because ImageBuffer still gets created and destroyed
> for every single frame, which causes us to recreate the pixmap for the
> canvas all the time.
> 
> My proposal would be as follows. We change Graphics Context so that it
> has an internal buffer (of ImageBuffer instance). For a graphics
> context that operates on a canvas, we just use its ImageBuffer for the
> painting, with some reference counting so everytime we clear the
> (Buffered)Image instance we don't need to throw the pixmap again and
> again.
> 
> Bonus: we can get rid of our ImageBufferData.
> 
> Also, this opens further optimization for pixel manipulation (which I
> have planned to do since ages, but then I am a lazy guy :). Currently
> getting or setting a pixel from our canvas converts the pixmap to an
> image and later back again to the pixmap (expensive on non-raster
> graphics systems). If we can keep both the pixmap and image ourselves,
> we might do some heuristic caching and optimization. For example,
> usually pixel manipulations are not interleaved with vector/path
> fill/stroke etc. This allows us to keep either the pixmap format or
> the image format as long as we need it and avoid constant conversion
> between them.
> 
> I'l try to give it a shot in the next few weeks. Ideas and feedbacks
> are warmly welcomed.
> 
> Thank you!
> 
> Regards,
> 
> 
> --
> Ariya Hidayat
> http://www.linkedin.com/in/ariyahidayat
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>