Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users
Status: Duplicate
Merged: issue 133590
Last visit > 30 days ago
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Sign in to add a comment
Consider exposing device scale factor setting in dev tools overrides
Project Member Reported by, Aug 24 2012 Back to list
With sites being designed for high-DPI, it's important that site designers have an easy way to test.

Today you can test on MacOS by using Quartz debug to simulate high-DPI mode, and you can test on ChromeOS by setting the 'force high-DPI mode' flag.  But if you do your development on Windows there is no easy way to test.

Would it be easy to add a 'device scale factor' override in the dev tools options (line the existing 'font scale factor')?
Status: Assigned
@aelias: Alexandre, what is the current state of the Android code upstreaming? Are we ready yet?
Comment 3 by, Aug 28 2012
Note that this isn't Android specific.  Eg. chrome on retina Mac Book pro uses a device scale factor of 2.
Comment 4 by, Aug 28 2012
Android is still using a different approach (folding device scale into page scale) so it's not worth trying hard at this point to make the mobile view in devtools support this option.  But it would be a reasonable option to add for the normal desktop view.
Labels: Hotlist-Link OS-Chrome
Labels: MStone-24
Tentatively calling this M24. If this is indeed simple, would M24 be reasonable?
I have ginven it a try in the past few days (essentially, all the code is there,) and something seems really borked either in WebCore or in WebKit/chromium, as the updates (with garbage instead of correct contents) and hit testing seem to occur for element locations/sizes computed with the DSF of 1, even though the original page is rendered with the emulation-specified DSF (e.g., 2). I followed aelias@'s advice (WebSettings), to no avail, and provided him with the WIP patch, even though I suspect the investigation may take quite a while (and alas, I'm not familiar with the Chrome-specific rendering/compositing code at all,) unless someone interested in the matter and/or proficient in the area chimes in. In this case M24 seems a reasonable target.
Can you describe how to 'give it a try' so we can see the effect you're describe?  I assume we want to follow exactly the same path that we do when the window moves to a monitor with a different scale factor.  

danakj@ or vollick@ may have some pointers / ideas.
@rbyers: I invoked

The presence of the first line did not make any difference. WIP patch emailed to rbyers.
Labels: -Hotlist-Link macdpi
Dev tools team to drive this
We talked about this over e-mail, I think we decided that it's not as trivial as I hoped to get good fake high-dpi support in the web contents area on mac without the OS itself being in high-dpi mode.  We'd have to at least write new code that transforms input event co-ordinates properly.  I still think this would be a nice feature to have, but I'm OK calling it won't fix - anyone that really cares about high-dpi will have a mac to test on.

Labels: -OS-Chrome -MStone-24
Mergedinto: 133590
Status: Duplicate
Let's track this feature in a single issue.

According to abarth@, the right way to implement this is through changing the compositor code, not WebCore.
Project Member Comment 13 by, Mar 11 2013
Labels: -Area-WebKit -Feature-HighDPI -Feature-DevTools Cr-Content Cr-Platform-DevTools Cr-UI-HighDPI
Project Member Comment 14 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment