Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
12398019:
Set the scale factor for the display on Windows when in high-DPI mode. (Closed)
DescriptionSet the scale factor for the display on Windows when in high-DPI mode.
BUG=149881
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=186170
Patch Set 1 #
Total comments: 4
Patch Set 2 : Fix bounds. #
Messages
Total messages: 15 (0 generated)
Oshima-san, Can you please take a look at this CL.
https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc File ui/gfx/screen_win.cc (right): https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... ui/gfx/screen_win.cc:27: display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); I believe you need to pass the display's bound (in pixel) instead of work area here, unless the meaning of work area is different on windows. Another q: I thought windows desktop and modern UI can have different scale factors. Am I wrong or are you going to address this later?
https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc File ui/gfx/screen_win.cc (right): https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... ui/gfx/screen_win.cc:27: display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); On 2013/03/04 19:34:25, oshima wrote: > I believe you need to pass the display's bound (in pixel) instead of work area > here, unless the meaning of work area > is different on windows. > > Another q: I thought windows desktop and modern UI can > have different scale factors. Am I wrong or are you going > to address this later? For Windows, the scale factor is fixed across all devices and based on the DPI-scale factor, which is set as an OS preference. Requires relogging for a change in scale factor to take effect. Will investigate if the display's bounds should be used.
On 2013/03/04 20:02:14, kevers wrote: > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc > File ui/gfx/screen_win.cc (right): > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... > ui/gfx/screen_win.cc:27: > display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); > On 2013/03/04 19:34:25, oshima wrote: > > I believe you need to pass the display's bound (in pixel) instead of work area > > here, unless the meaning of work area > > is different on windows. > > > > Another q: I thought windows desktop and modern UI can > > have different scale factors. Am I wrong or are you going > > to address this later? > > For Windows, the scale factor is fixed across all devices and based on the > DPI-scale factor, which is set as an OS preference. Requires relogging for a > change in scale factor to take effect. > > Will investigate if the display's bounds should be used. IIRC, modern UI uses 100/140/180 while desktop is arbitrary (although our preference is 100/125/150). What happen if a user has 140 on modern UI while desktop has other scale factors?
https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc File ui/gfx/screen_win.cc (right): https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... ui/gfx/screen_win.cc:27: display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); On 2013/03/04 19:34:25, oshima wrote: > I believe you need to pass the display's bound (in pixel) instead of work area > here, unless the meaning of work area > is different on windows. The "work area" on windows is the area excluding OS controls (like the toolbar), so this code is correct. > > Another q: I thought windows desktop and modern UI can > have different scale factors. Am I wrong or are you going > to address this later? Windows does not support multiple simultaneous scale factors, so we won't have to worry about this.
On 2013/03/04 21:51:23, oshima wrote: > On 2013/03/04 20:02:14, kevers wrote: > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc > > File ui/gfx/screen_win.cc (right): > > > > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... > > ui/gfx/screen_win.cc:27: > > display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); > > On 2013/03/04 19:34:25, oshima wrote: > > > I believe you need to pass the display's bound (in pixel) instead of work > area > > > here, unless the meaning of work area > > > is different on windows. > > > > > > Another q: I thought windows desktop and modern UI can > > > have different scale factors. Am I wrong or are you going > > > to address this later? > > > > For Windows, the scale factor is fixed across all devices and based on the > > DPI-scale factor, which is set as an OS preference. Requires relogging for a > > change in scale factor to take effect. > > > > Will investigate if the display's bounds should be used. > > IIRC, modern UI uses 100/140/180 while desktop is arbitrary (although our > preference is 100/125/150). > What happen if a user has 140 on modern UI while desktop has other scale > factors? The "content" portion of the browser will scale to the user's exact setting (150%). The "views" portion of the browser will scale to the closest available asset class (in this case, 140%).
On 2013/03/04 21:56:09, girard wrote: > On 2013/03/04 21:51:23, oshima wrote: > > On 2013/03/04 20:02:14, kevers wrote: > > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc > > > File ui/gfx/screen_win.cc (right): > > > > > > > > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... > > > ui/gfx/screen_win.cc:27: > > > display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); > > > On 2013/03/04 19:34:25, oshima wrote: > > > > I believe you need to pass the display's bound (in pixel) instead of work > > area > > > > here, unless the meaning of work area > > > > is different on windows. > > > > > > > > Another q: I thought windows desktop and modern UI can > > > > have different scale factors. Am I wrong or are you going > > > > to address this later? > > > > > > For Windows, the scale factor is fixed across all devices and based on the > > > DPI-scale factor, which is set as an OS preference. Requires relogging for > a > > > change in scale factor to take effect. > > > > > > Will investigate if the display's bounds should be used. > > > > IIRC, modern UI uses 100/140/180 while desktop is arbitrary (although our > > preference is 100/125/150). > > What happen if a user has 140 on modern UI while desktop has other scale > > factors? > > The "content" portion of the browser will scale to the user's exact setting > (150%). The "views" portion of the browser will scale to the closest available > asset class (in this case, 140%). Chatted offline and it seems like desktop is designed to use same scale factor as modern UI, so this CL LGTM.
On 2013/03/04 21:56:09, girard wrote: > On 2013/03/04 21:51:23, oshima wrote: > > On 2013/03/04 20:02:14, kevers wrote: > > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc > > > File ui/gfx/screen_win.cc (right): > > > > > > > > > https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... > > > ui/gfx/screen_win.cc:27: > > > display.SetScaleAndBounds(ui::win::GetDeviceScaleFactor(), work_area); > > > On 2013/03/04 19:34:25, oshima wrote: > > > > I believe you need to pass the display's bound (in pixel) instead of work > > area > > > > here, unless the meaning of work area > > > > is different on windows. > > > > > > > > Another q: I thought windows desktop and modern UI can > > > > have different scale factors. Am I wrong or are you going > > > > to address this later? > > > > > > For Windows, the scale factor is fixed across all devices and based on the > > > DPI-scale factor, which is set as an OS preference. Requires relogging for > a > > > change in scale factor to take effect. > > > > > > Will investigate if the display's bounds should be used. > > > > IIRC, modern UI uses 100/140/180 while desktop is arbitrary (although our > > preference is 100/125/150). > > What happen if a user has 140 on modern UI while desktop has other scale > > factors? > > The "content" portion of the browser will scale to the user's exact setting > (150%). The "views" portion of the browser will scale to the closest available > asset class (in this case, 140%). Currently, the "content" portion is also scaled to the closest supported scale on Win-Aura. Some work is required on the non-accelerated backing store to support an arbitrary scale factor. On the TODO list.
https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc File ui/gfx/screen_win.cc (right): https://chromiumcodereview.appspot.com/12398019/diff/1/ui/gfx/screen_win.cc#n... ui/gfx/screen_win.cc:24: gfx::Display display(0, gfx::Rect(monitor_info.rcMonitor)); Oh, wait. So this was wrong? Or size of rcMonitor == size of rcWork?
Fixed the bounds.
lgtm
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/kevers@chromium.org/12398019/9001
Retried try job too often on win7_aura for step(s) browser_tests http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win7_aura&...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/kevers@chromium.org/12398019/9001
Message was sent while issue was closed.
Change committed as 186170 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
