Promoting elements with subpixel size for accelerated animations can cause 1px jitter.
Reported by
anssi.ha...@gmail.com,
Jul 13 2016
|
|||||||||||
Issue description
Chrome Version : 51.0.2704.106 m (on Windows 10),
53.0.2785.8 dev (64-bit) (on Linux)
URLs (if applicable) : https://jsfiddle.net/ca08f5h7/
Other browsers tested:
Firefox: OK, ESR 45.2.0
IE: OK, 11.212.10586.0
What steps will reproduce the problem?
(1) Open the above URL.
(2) Hover over the 2nd, 4th, or 7th image "column".
What is the expected result?
The opacity smoothly transitions to 1.0 on hover. Image size is not affected.
What happens instead?
The image width seems to be reduced by 1 pixel during the transition, seen on the right-side edge of the image. After the transition the image goes back to being 1 px wider.
This seems to be triggered by a combination of opacity transition and a subpixel img CSS width (155.4px in the example). A subpixel img width can easily happen with e.g. a percentage-based column layout with full-width images within those columns.
Altering the width value of the imgs causes different results. E.g. with 155.5px there is a widening effect (instead of shrinking) on opacity transition on the 2nd, 4th, and 6th columns.
Attached is a screenshot taken during the transition.
,
Jul 15 2016
,
Jul 20 2016
Applying will-change: opacity has the same effect. This is a rounding issue; basically some of the 155.4px wide images are drawn 156px wide depending on their x location on the page, however when we promote the image into its own layer (i.e. while running an accelerated animation) we draw it at a consistent 155px, I'm guessing because we don't re-raster composited elements based on their current location on the page so we can't round their size according to their positions. Do we have an existing bug for subpixel sizes leading to width changes during animations?
,
Jul 20 2016
I'm working on subpixel issue recently. Although this bug has a mechanism different from the other bug I'm trying to solve, but they fall into the same category of "compositing decision affects rendering results". FYI: We always apply pixel snapping on their layout position (i.e. ignoring transforms), so even if the element has an active animation its layout position should be considered the same and snapped the same way. I guess either we screwed up subpixel accumulation, or calculated compositing bounds wrong.
,
Jul 21 2016
Turns out it is due to directly composited images not having its contents rect snapped properly. https://codereview.chromium.org/2172503002/
,
Jul 21 2016
Since this issue is in compositing land, I'll remove the Blink>Animation label. I'm cc'd on the issue; let me know if you need anything from the Animations team.
,
Jul 21 2016
Is issue 531422 a dup of this one?
,
Jul 21 2016
I think not. This bug is a pure compositing bug. Issue 531422 doesn't involve anything beyond layout. I can investigate it after finishing stuff on my plate.
,
Jan 24 2017
,
Jun 13 2017
Removing myself from this bug since it doesn't look like the input of the Animations team is needed. Reach out to meade@ if that's not the case.
,
Sep 13
I'm leaving the team thus re-assigning bugs. This is still reproducible as of today. This is surprising because I thought layout snapping is implement quite rigorous now with SPv175.
,
Oct 8
,
Oct 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f02017ac12c8452a9f99e8086ffe8321e04c355a commit f02017ac12c8452a9f99e8086ffe8321e04c355a Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Wed Oct 17 01:47:33 2018 Reduce rounding errors in hit testing on high-dpi Previously we use ToCeiledPoint for the input of InputTargetClient::FrameSinkIdAt(). The input is in DIP so the ceiling caused too much error for blink hit testing which uses css pixels which is in device pixels when use-zoom-for-dsf is enabled. The error also accumulated across frame boundaries. Now pass PointF to InputTargetClient::FrmeSinkIdAt(), and round it (in blink pixels) when passing it to blink. I discovered the issue when trying to land https://chromium-review.googlesource.com/c/chromium/src/+/1271582 which changes the subpixel position of iframe contents. Bug: 627683 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: If3b9d9ca2ee6fa553ac0274011456938b1a606d2 Reviewed-on: https://chromium-review.googlesource.com/c/1280312 Reviewed-by: Timothy Dresser <tdresser@chromium.org> Reviewed-by: Nasko Oskov <nasko@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#600234} [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/browser/renderer_host/render_widget_targeter.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/browser/site_per_process_hit_test_browsertest.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/input/input_target_client_impl.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/input/input_target_client_impl.h [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/input/render_widget_input_handler.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/input/render_widget_input_handler.h [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/render_widget.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/render_widget.h [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/content/renderer/render_widget_browsertest.cc [modify] https://crrev.com/f02017ac12c8452a9f99e8086ffe8321e04c355a/services/viz/public/interfaces/hit_test/input_target_client.mojom
,
Oct 18
A reminder to remove the temporary gpu pixel_test rebaseline directives.
,
Oct 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c commit ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Thu Oct 18 17:26:21 2018 [PE] Fix subpixel accumulation for composited content layers The content box rect was improperly snapped in the local space. We should snap in the layout space instead, including subpixel accumulation. This is a duplicate of trchen@'s old CL https://codereview.chromium.org/2172503002/ rebased on the current trunk. Bug: 627683 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_layout_tests_slimming_paint_v2;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I737871c4bafead28f1040d486a59f3203c0b0ead Reviewed-on: https://chromium-review.googlesource.com/c/1271582 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Kenneth Russell <kbr@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#600811} [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/content/test/gpu/gpu_tests/pixel_expectations.py [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/content/test/gpu/gpu_tests/pixel_test_pages.py [add] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/compositing/composited-replaced-subpixel-location-expected.html [add] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/compositing/composited-replaced-subpixel-location.html [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/platform/linux/virtual/gpu/fast/canvas/canvas-toDataURL-jpeg-maximum-quality-expected.png [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/platform/mac/virtual/gpu/fast/canvas/canvas-toDataURL-jpeg-maximum-quality-expected.png [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/platform/mac/virtual/gpu/fast/canvas/canvas-toDataURL-webp-expected.png [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/platform/win/virtual/gpu/fast/canvas/canvas-toDataURL-jpeg-maximum-quality-expected.png [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/WebKit/LayoutTests/platform/win/virtual/gpu/fast/canvas/canvas-toDataURL-webp-expected.png [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.cc [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.h [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping_test.cc [modify] https://crrev.com/ec37d4ccf840857b7fa5f7ae95a034c5ee2a469c/third_party/blink/renderer/core/paint/embedded_content_painter.cc
,
Oct 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/70179d64018cbe98e6d2ccbf5d366b404cc20c8d commit 70179d64018cbe98e6d2ccbf5d366b404cc20c8d Author: Xianzhu Wang <wangxianzhu@chromium.org> Date: Thu Oct 18 20:51:20 2018 Remove temporary failure expectations for Pixel_OffscreenCanvasTransferToImageBitmap etc. Bug: 627683 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: Ib5e777a993b64f2efaf1b4f0952e506f8e3010a0 TBR: kbr@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/1289389 Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#600895} [modify] https://crrev.com/70179d64018cbe98e6d2ccbf5d366b404cc20c8d/content/test/gpu/gpu_tests/pixel_expectations.py
,
Oct 18
,
Oct 22
The NextAction date has arrived: 2018-10-22 |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by brajkumar@chromium.org
, Jul 14 2016Labels: M-54 OS-Linux OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)