Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(155)

Issue 1697483003: Properly scale the coordinate for TouchSelection when use-zoom-for-dsf mode is on.

Created:
4 years, 10 months ago by oshima
Modified:
4 years, 9 months ago
Reviewers:
danakj, mohsen, no sievers
CC:
cc-bugs_chromium.org, chromium-reviews, creis+watch_chromium.org, darin-cc_chromium.org, jam, nasko+codewatch_chromium.org
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

Properly scale the coordinate for TouchSelection when use-zoom-for-dsf mode is on. * The selection bounds is sent as a part of meta data. painted_dsf is set to 2x on 2x device when use-zoom-for-dsf mode is on. * The bounds sent from browser is in Window coordinates. It should be converted to Viweport, which is pixels when use-zoom-for-dsf mode is on. BUG=585043 TEST=LayerTreeHostimplTestWithPaintedDeviceScaleFactor.SelectionBoundsPassedToCompositorFrameMetaData manually tested on high DPI device TBR=oshima@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Patch Set 1 #

Patch Set 2 : #

Patch Set 3 : #

Patch Set 4 : #

Patch Set 5 : #

Patch Set 6 : #

Patch Set 7 : #

Total comments: 2
Unified diffs Side-by-side diffs Delta from patch set Stats (+37 lines, -14 lines) Patch
M cc/trees/layer_tree_host_impl_unittest.cc View 1 2 3 4 2 chunks +27 lines, -3 lines 2 comments Download
M cc/trees/layer_tree_impl.cc View 1 2 3 4 2 chunks +4 lines, -5 lines 0 comments Download
M content/renderer/render_frame_impl.cc View 1 2 3 4 5 6 2 chunks +4 lines, -4 lines 0 comments Download
M content/renderer/render_view_impl.cc View 1 2 3 4 5 6 1 chunk +2 lines, -2 lines 0 comments Download

Messages

Total messages: 28 (15 generated)
commit-bot: I haz the power
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1697483003/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1697483003/20001
4 years, 10 months ago (2016-02-16 08:10:01 UTC) #3
commit-bot: I haz the power
Dry run: This issue passed the CQ dry run.
4 years, 10 months ago (2016-02-16 09:18:48 UTC) #5
commit-bot: I haz the power
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1697483003/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1697483003/80001
4 years, 10 months ago (2016-02-19 20:58:30 UTC) #7
commit-bot: I haz the power
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1697483003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1697483003/100001
4 years, 10 months ago (2016-02-19 23:20:57 UTC) #9
commit-bot: I haz the power
Dry run: This issue passed the CQ dry run.
4 years, 10 months ago (2016-02-20 00:40:10 UTC) #11
oshima
mohsen@, I'm sending this to you because you seemed to have worked on this feature ...
4 years, 10 months ago (2016-02-22 22:42:03 UTC) #17
commit-bot: I haz the power
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1697483003/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1697483003/120001
4 years, 10 months ago (2016-02-22 22:44:14 UTC) #19
commit-bot: I haz the power
Dry run: This issue passed the CQ dry run.
4 years, 10 months ago (2016-02-23 00:01:53 UTC) #21
mohsen
Changes look good to me, though I've mostly worked on the browser side of touch ...
4 years, 10 months ago (2016-02-23 18:34:50 UTC) #22
oshima
+danakj@ -> cc/ owner +sievers@ -> content/renderer owner, who also revered the CL https://codereview.chromium.org/657803002, which ...
4 years, 10 months ago (2016-02-23 18:46:54 UTC) #24
oshima
friendly ping
4 years, 10 months ago (2016-02-25 19:00:33 UTC) #25
danakj
https://codereview.chromium.org/1697483003/diff/120001/cc/trees/layer_tree_host_impl_unittest.cc File cc/trees/layer_tree_host_impl_unittest.cc (right): https://codereview.chromium.org/1697483003/diff/120001/cc/trees/layer_tree_host_impl_unittest.cc#newcode8032 cc/trees/layer_tree_host_impl_unittest.cc:8032: EXPECT_EQ(gfx::ScalePoint(gfx::PointF(selection_bottom), Does this all mean that there is some ...
4 years, 10 months ago (2016-02-25 19:37:22 UTC) #26
oshima
4 years, 10 months ago (2016-02-25 21:52:03 UTC) #27
https://codereview.chromium.org/1697483003/diff/120001/cc/trees/layer_tree_ho...
File cc/trees/layer_tree_host_impl_unittest.cc (right):

https://codereview.chromium.org/1697483003/diff/120001/cc/trees/layer_tree_ho...
cc/trees/layer_tree_host_impl_unittest.cc:8032:
EXPECT_EQ(gfx::ScalePoint(gfx::PointF(selection_bottom),
On 2016/02/25 19:37:22, danakj wrote:
> Does this all mean that there is some input to the compositor that isn't being
> scaled by the painted device scale factor?
> 
> I'm not expecting cc to have to use the painted DSF for anything other than
> passing it along. So I'd expect all inputs to already be scaled.

This is an output from compositor. Currently, cc/ is responsible for computing
the selection bounds, which is attached to the frame metadata, which in turn, is
consumed by browser process in DIP.  See ComputeViewportSelectionBound (It
converts from layer -> screen -> dip).

Other selection code lives in content/renderer so it's not clear to me why this
is in cc/ though.

While it's technically possible to move the conversion to browser process, but
I'd like to avoid it because browser currently expects to receive DIP from
renderer process.

Powered by Google App Engine
This is Rietveld 408576698