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
>
> <hy...@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
> (hy...@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.robin...@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@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
