[Webkit-unassigned] [Bug 73186] [Chromium]Draw small cached canvases to an onscreen large canvas is slow when 2D canvas is HW accelerated.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Dec 9 07:54:25 PST 2011


https://bugs.webkit.org/show_bug.cgi?id=73186





--- Comment #6 from Stephen White <senorblanco at chromium.org>  2011-12-09 07:54:25 PST ---
(In reply to comment #5)
> Thanks for your remainder, I just tested the non-static case you mentioned: I randomly draw rect with different color(fillRect) into the cached canvas, the texture was not re-uploaded.
> After debug, I found the root cause is as follow:
> 1. in fillRect to the cached canvas, it use canvas->fDevice->bitmap to finish the operation. As pixels changed, the bitmap's generation id will set to 0;
> 2. when draw this cached canvas to accelerated big canvas, it will use m_data.m_image->bitmap(as my fix) to finish the operation. the bitmap's generation id is not 0, so we will use this id to find the cached texture, the texture is not re-loaded.
> 
> I tried the below code, that is to check bitmap's content is changed before we draw. It works and the texture will be re-uploaded after the source canvas content changed:
>     // if the bitmap's content has changed, we have to update m_image.
>     if( m_data.m_platformContext.bitmap()->getGenerationID() != m_data.m_image.get()->nativeImageForCurrentFrame()->bitmap().getGenerationID()) 

I don't think explicitly checking the generation ID is that right way to go; this should be handled internally (although perhaps Brian can comment on that).

I'm wondering if the root cause of this issue might be related to
https://bugs.webkit.org/show_bug.cgi?id=74183.  If that issue were fixed, perhaps we could come up with a cleaner fix to this issue as well.

{
>         m_data.m_image = BitmapImageSingleFrameSkia::create(*m_data.m_platformContext.bitmap(), false);
>     }
> 
>     if (drawNeedsCopy(m_context.get(), context)) {
>         // We are drawing to our own buffer, copy the source buffer first
>         RefPtr<Image> copy = copyImage(CopyBackingStore);
>         context->drawImage(copy.get(), styleColorSpace, destRect, srcRect, op, useLowQualityScale);
>     } else
>         context->drawImage(m_data.m_image.get(), styleColorSpace, destRect, srcRect, op, useLowQualityScale);
> 
> Any suggestion to it? Thanks
> 
> (In reply to comment #4)
> > (From update of attachment 116699 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=116699&action=review
> > 
> > > Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp:122
> > > +    m_data.m_image = BitmapImageSingleFrameSkia::create(*m_data.m_platformContext.bitmap(), false);
> > 
> > Thank you for the patch.
> > 
> > I'm wondering how this change will behave in the non-static case:  if you subsequently change the source canvas and re-draw it to the destination, since this bitmap has already been copied will it be successfully generation-bumped and the texture re-uploaded?  Have you tested this case?
> > 
> > > Source/WebCore/platform/graphics/skia/ImageBufferSkia.cpp:164
> > > +    if (context == m_context) {
> > 
> > I've been changing this code a bit recently.  You'll have to sync up to tip-of-tree, since this condition has changed.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list