[webkit-dev] Canvas performance and memory usage

[Christophe Public]

Thanks for the clarification. If this is the main reason, then it seems a
valuable optimization to do.
Christophe

On Wed, Aug 4, 2010 at 2:52 PM, Oliver Hunt <oliver at apple.com> wrote:

> The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is
> almost exclusively for the purpose of ensuring correct behaviour in the case
> where a canvas is drawn onto itself, eg.
>
> context = myCanvas.getContext("2d");
> context.drawImage(myCanvas, 0, 0);
>
> Off hand I can think of no other case where this would be necessary, so it
> seems like the best solution would be to make the default behaviour for
> image() be to return a reference to a potentially mutable image, and to give
> the canvas a distinct method for getting a copied image in the case where
> it's actually necessary.
>
> --Oliver
>
> On Aug 4, 2010, at 2:45 PM, Christophe Public wrote:
>
> 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
>>
>
> _______________________________________________
> 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/6d304c0e/attachment.html>