[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