Bug 86884 – [chromium] Expand damage from the background-blurred layer to ensure readback is only including pixels below that layer

• Component: New Bugs
• Status: RESOLVED FIXED

[Dana Jansens]

[chromium] Expand damage from the background-blurred layer to ensure readback is only including pixels below that layer

[Dana Jansens]

Created attachment 142765 [details]
Patch

[Adrienne Walker]

Comment on attachment 142765 [details]
Patch

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.

[Dana Jansens]

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.

[Dana Jansens]

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.

[Adrienne Walker]

(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.

[Adrienne Walker]

Comment on attachment 142765 [details]
Patch

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.  :)

[WebKit Review Bot]

Comment on attachment 142765 [details]
Patch

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

[Dana Jansens]

Created attachment 143310 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 143310 [details]
Patch for landing

Clearing flags on attachment: 143310

Committed r117981: <http://trac.webkit.org/changeset/117981>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.