[webkit-dev] Canvas performance and memory usage

[Christophe Public]

Hi,

Actually, I was questioning also the necessity of this extra buffer.
I'll just give an update and some numbers. We have a very large canvas (few
MB) and our updates are very frequent but very small (clip area is for
example 3x3 pixels), it takes about 25ms for our system to handle the
expose. Once the double buffer is removed, the expose takes less than 1ms.

We applied our change to image(). When the BitmapImage is created, we now
pass the m_data.m_surface after increasing its reference count through
cairo_surface_reference and removed the copy.

Our tests didn't detect any issue after this change.

Christophe

On Wed, Aug 4, 2010 at 11:07 AM, David Hyatt

<hyatt at apple.com> wrote:

> I'm confused why a special method is needed though.  Can't image() just
> avoid the full copy?  Given how we use image() in WebKit, I don't think
> there's any reason to be concerned if image() continues to reflect the
> contents of the ImageBuffer.  I think we should just switch to that model
> for the CG port also anyway, since I'm unconvinced we're truly avoiding a
> copy, and return an image with a custom data provider that feeds the current
> contents of the ImageBuffer to the image.
>
> dave
> (hyatt at apple.com)
>
> On Aug 3, 2010, at 8:55 PM, Martin Robinson wrote:
>
> > Resent from the proper address:
> >
> > On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson
> > <martin.james.robinson at gmail.com> wrote:
> >>> I notice that Qt added imageForRendering() and felt they could not use
> >>> image() for some reason.  I'd be curious if a Qt expert could weigh in
> on
> >>> that, since maybe with a redesign a separate call would not be needed.
> >
> > I'm not a Qt expert, but just based on a quick look, it seems that
> > imageForRendering  avoids the full QPixmap copy. Christophe,
> > when you open a bug for this issue,  please CC me, as I have a
> > small patch in my tree which has the same imageForRendering
> > pecialization, but for Cairo.
> >
> > Martin
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100804/ccad9336/attachment.html>