Issue metadata
Sign in to add a comment
|
High dpi does not scale damage for pepper2d
Reported by
avsha...@etouch.net,
Nov 16 2017
|
||||||||||||||||||||||
Issue descriptionChrome Version : 64.0.3269.3 (Official Build) 1d74d56f7fb838be3c05549bc5e11cdf665f1990-refs/branch-heads/3269@{#3} 64-bit OS : Mac Touchbar(10.13.2), Mac Retina(10.12.6) Test URL : http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf What steps will reproduce the problem? 1. Launch chrome and navigate to above test URL (let the PDF load completely). 2. Now try to pinch zoom in and out PDF page using touchpad and observe the PDF. (Kindly review an attached screencast) Actual Result : Pinch zoom is not smooth for PDF and PDF page appears weird while performing pinch zoom action. Expected Result : Pinch zoom action should be smooth for PDF pages. This is a regression issue broken in ‘M-64’ and using the per-revision bisect providing the bisect results, Good build : 64.0.3268.0 (Revision : 512148) Bad build : 64.0.3269.0 (Revision : 516552) You are probably looking for a change made after 516477 (known good), but no later than 516478 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/82fbfa3c1e52688d48e3968fdfd9cf33f1b915b6..cfab550a8e384b0e43fd104121a9be7a0a4db968 Suspect : https://chromium.googlesource.com/chromium/src/+/cfab550a8e384b0e43fd104121a9be7a0a4db968 @danakj : Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner. Note : Issue is not reproducible on Windows(7,8,10) & Linux(14.04 LTS)
,
Nov 16 2017
Sending over to mcnee@ who did the pinch-zoom work for PDFs. I believe this code is all new, we didn't handle pinch-zoom on a trackpad previously, so I don't think this is a release block.
,
Nov 16 2017
The behaviour in the expected video shows the PDF viewer handling the pinch correctly (which originally landed on Nov 13). So this doesn't appear to be related to the introduction of the handling in the viewer itself, but a regression that happened since the introduction. In the actual video, the PDF viewer is still handling the pinch, but the scale changes only for the upper left quarter of the PDF content, while the rest gets frozen at a given scale and then snaps back to the correct scale. The suspected CL mentions the possibility of "pepper getting out of sync with the compositor", so perhaps there's an issue with pepper's SetLayerTransform which we use in the PDF viewer to scale the PDF's bitmap.
,
Nov 16 2017
The CL moves the texture upload from TextureLayerImpl to the pepper2d host. Along the way it also ensured that the dirty flag is changed when moving between gpu and software compositing modes. The sync there it refers to is the compositing mode: gpu vs software compositing. This changes when the context is lost, not on pinch or something.
,
Nov 16 2017
The bug looks to me like its missing damage, like the report to the compositor of what has changed is being scaled by the pinch or something. But I can't see where my CL would change that. The old upload path didn't add any damage: https://chromium-review.googlesource.com/c/chromium/src/+/692999/24/cc/layers/texture_layer_impl.cc
,
Nov 16 2017
> Note : Issue is not reproducible on Windows(7,8,10) & Linux(14.04 LTS) Maybe mac is using partial swap but windows/linux aren't, could explain if it is damage related. This is where damage gets reported fwiw: https://cs.chromium.org/chromium/src/content/renderer/pepper/pepper_plugin_instance_impl.cc?rcl=2b344530d6d9c7898e2cb626880a8e841e5922ce&l=751
,
Nov 16 2017
I just tried this on ToT on a Mac and wasn't able to reproduce.
,
Nov 16 2017
The video looks like damage is missing DPI scaling.
,
Nov 16 2017
Thanks. That was it. I tried with HiDPI and was able to reproduce. It looks like the |invalidated_rect| set by SetLayerTransform doesn't account for the scaling. https://cs.chromium.org/chromium/src/content/renderer/pepper/pepper_graphics_2d_host.cc?rcl=874c50528a8520f3c4990d3a464bc172588ada9d&l=841
,
Nov 16 2017
Mmh, I was wondering why Dana's CL changes that, I think what happens is that it kicks us off the CA compositing, and so we likely behave differently wrt damage: before we would use ResourceProvider to create the resource, which would create a GMB (that we can push to CA), whereas now we create a plain-old-texture, which we can't push to CA, so we fall back to GLRenderer. It sounds like we want to fix both things.
,
Nov 16 2017
This will be hard to fix without a mac but I'll give that a try. I will split that off into another bug and leave this one about damage since it has all that context.
,
Nov 16 2017
https://bugs.chromium.org/p/chromium/issues/detail?id=786140 for the GpuMemoryBuffer thing.
,
Nov 20 2017
Once 786140 is fixed, the bug will become hidden. In order to fix the damage issue, you can use --disable-mac-overlays to disable the fix I'm landing for that bug.
,
Nov 20 2017
Oops, I double checked with ccameron and the flags would be these actually: --disable-zero-copy --disable-native-gpu-memory-buffers
,
Nov 20 2017
,
Nov 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a140876f4c9377e89a8e23b57face1a141325085 commit a140876f4c9377e89a8e23b57face1a141325085 Author: Kevin McNee <mcnee@chromium.org> Date: Tue Nov 21 15:10:10 2017 Pepper: Account for DPI scaling for damage of SetLayerTransform. Bug: 785801 Change-Id: I0bcc31cc9f90205d1c5c0181f25394f48f845605 Reviewed-on: https://chromium-review.googlesource.com/780180 Reviewed-by: Antoine Labour <piman@chromium.org> Commit-Queue: Kevin McNee <mcnee@chromium.org> Cr-Commit-Position: refs/heads/master@{#518252} [modify] https://crrev.com/a140876f4c9377e89a8e23b57face1a141325085/content/renderer/pepper/pepper_graphics_2d_host.cc
,
Nov 21 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by rbasuvula@chromium.org
, Nov 16 2017