My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 144635: Consider exposing device scale factor setting in dev tools overrides
15 people starred this issue and may be notified of changes. Back to list
Project Member Reported by, Aug 24, 2012
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')?
Aug 27, 2012
(No comment was entered for this change.)
Status: Assigned
Aug 28, 2012
@aelias: Alexandre, what is the current state of the Android code upstreaming? Are we ready yet?
Aug 28, 2012
Note that this isn't Android specific.  Eg. chrome on retina Mac Book pro uses a device scale factor of 2.
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.
Sep 5, 2012
(No comment was entered for this change.)
Labels: Hotlist-Link OS-Chrome
Sep 7, 2012
Tentatively calling this M24. If this is indeed simple, would M24 be reasonable?
Labels: MStone-24
Sep 7, 2012
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.
Sep 8, 2012
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.
Sep 8, 2012
@rbyers: I invoked

The presence of the first line did not make any difference. WIP patch emailed to rbyers.
Oct 24, 2012
Dev tools team to drive this
Labels: -Hotlist-Link macdpi
Oct 24, 2012
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.

Dec 6, 2012
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.
Status: Duplicate
Labels: -OS-Chrome -MStone-24
Mergedinto: 133590
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-WebKit -Feature-HighDPI -Feature-DevTools Cr-Content Cr-Platform-DevTools Cr-UI-HighDPI
Apr 5, 2013
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Sign in to add a comment

Powered by Google Project Hosting