Bug 86884 - [chromium] Expand damage from the background-blurred layer to ensure readback is only including pixels below that layer
: [chromium] Expand damage from the background-blurred layer to ensure readback...
Status: RESOLVED FIXED
: WebKit
New Bugs
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-05-18 12:39 PST by
Modified: 2012-05-22 09:09 PST (History)


Attachments
Patch (9.87 KB, patch)
2012-05-18 12:44 PST, Dana Jansens
no flags Review Patch | Details | Formatted Diff | Diff
Patch for landing (9.89 KB, patch)
2012-05-22 08:43 PST, Dana Jansens
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-05-18 12:39:04 PST
[chromium] Expand damage from the background-blurred layer to ensure readback is only including pixels below that layer
------- Comment #1 From 2012-05-18 12:44:05 PST -------
Created an attachment (id=142765) [details]
Patch
------- Comment #2 From 2012-05-21 12:39:54 PST -------
(From update of attachment 142765 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=142765&action=review

> Source/WebCore/ChangeLog:15
> +        Consider layers in back-to-front order A, B, and C, where layer B has
> +        a blur background filter applied, and C exactly covers A. When B does
> +        its readback to perform its blur, it should include the pixels of A
> +        not C. With partial swap, if B is damaged, that damaged area will read
> +        pixels from outside of the damage rect. Those pixels should use the
> +        contents of A, not C, so we must expand the damage to ensure we redraw
> +        all pixels that are going to be included in the blur for the current
> +        frame.

How does C enter into this? I understand that if B is damaged we need to expand the damage to include B and layers below B, but that doesn't seem to be affected by C.
------- Comment #3 From 2012-05-21 15:42:14 PST -------
C draws over top of A. If you damage B and do a readback on the next frame (with partial swap), you will be reading the pixels of C instead of A.
------- Comment #4 From 2012-05-21 16:08:43 PST -------
http://i.imgur.com/2zlPR.png

Hope this helps.

The blue damage should be expanded so that the pixels read back to draw it are blurring the contents of A not C.
------- Comment #5 From 2012-05-21 16:48:30 PST -------
(In reply to comment #3)
> C draws over top of A. If you damage B and do a readback on the next frame (with partial swap), you will be reading the pixels of C instead of A.

Sure, but this patch is about damage rects, not about readback order.  Wouldn't you need the exact same damage rect regardless of whether C was involved?

I'm just trying to understand why you constructed the example like that, because I feel like I'm missing something.
------- Comment #6 From 2012-05-21 17:17:19 PST -------
(From update of attachment 142765 [details])
Ok, I see.  The damage rects are still wrong even if C isn't there, but having C in the example makes the readback pixels wrong too.  Sorry for my confusion.  :)
------- Comment #7 From 2012-05-21 18:13:24 PST -------
(From update of attachment 142765 [details])
Rejecting attachment 142765 [details] from commit-queue.

Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2

Last 500 characters of output:
mit-queue/Source/WebKit/chromium/third_party/skia/src --revision 3995 --non-interactive --force --accept theirs-conflict --ignore-externals' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
45>At revision 3995.

________ running '/usr/bin/python tools/clang/scripts/update.py --mac-only' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'

________ running '/usr/bin/python gyp_webkit' in '/mnt/git/webkit-commit-queue/Source/WebKit/chromium'
Updating webkit projects from gyp files...

Full output: http://queues.webkit.org/results/12749138
------- Comment #8 From 2012-05-22 08:43:46 PST -------
Created an attachment (id=143310) [details]
Patch for landing
------- Comment #9 From 2012-05-22 09:09:28 PST -------
(From update of attachment 143310 [details])
Clearing flags on attachment: 143310

Committed r117981: <http://trac.webkit.org/changeset/117981>
------- Comment #10 From 2012-05-22 09:09:34 PST -------
All reviewed patches have been landed.  Closing bug.