summaryrefslogtreecommitdiffstats
path: root/device
diff options
context:
space:
mode:
authorpdr <pdr@chromium.org>2016-02-26 15:24:02 -0800
committerCommit bot <commit-bot@chromium.org>2016-02-26 23:25:35 +0000
commitd1e45374111c047fc69c8719434bf14417f74d2e (patch)
tree915ecb4f4d51aa24f1e62ed4f90fa593b4fe5003 /device
parent472b66e620c090e3fe5d7a725ee684b046a61280 (diff)
downloadchromium_src-d1e45374111c047fc69c8719434bf14417f74d2e.zip
chromium_src-d1e45374111c047fc69c8719434bf14417f74d2e.tar.gz
chromium_src-d1e45374111c047fc69c8719434bf14417f74d2e.tar.bz2
Update drag images to paint from the nearest self painting layer
Before this patch there were two codepaths for painting drag images: 1) Boxes were drawn using paintAsPseudoStackingContext which would fail to paint composited children (https://crbug.com/585611). 2) Everything else was drawn using paintIntoDragImage which paints starting at the view so any transparent regions of the drag element would be filled in with the content behind the drag element. This patch unifies drag image rendering under a single approach where painting begins at the nearest self painting layer to the dragged element. This has two nice properties: 1) self painting children are painted. 2) transparency is supported as long as the drag element has a layer. Neither Safari nor Firefox really support these usecases so this approach is a best-effort at supporting common usecases without invasive surgery on the paint code. Some behavior is different such as not including the dragged element's transform. As part of this patch, paintIntoDragImage has been merged into dragImageForSelection which is now the only caller. BUG=585611 Review URL: https://codereview.chromium.org/1736893002 Cr-Commit-Position: refs/heads/master@{#378021}
Diffstat (limited to 'device')
0 files changed, 0 insertions, 0 deletions