Tracking bug for issues that need pixel-precise positioning |
|||||||||
Issue descriptionSome UI elements need to pop-up and float on top of other UI elements. This is normally accomplished by giving the element its own hwnd and positioning it in screen coordinates. But because everything in views is done via DIPs there are some pixel positions that are not possible to represent (for example at 2.0 dsf an odd pixel position can't be represented). So some elements are misaligned because they need a precise position that falls into this "dead zone." Pixel-precise positioning is in the works. When it's available it should be pretty easy to clean them up, provided we know about them. So I'm attempting to keep them all tracked here.
,
Nov 23 2016
GlassBrowserFrameView uses FrameTopBorderThicknessPx to work around this, so we should remove it when it's no longer necessary.
,
Nov 23 2016
Windows10CaptionButton::GetPreferredSize wants to be in pixels so that it can match Windows at all scale factors (see the TODO). There's also a TODO in the VIEW_ID_CLOSE_BUTTON block about drawing misaligned, but again that should Just Work if everything is pixel-aligned.
,
Dec 2 2016
,
Mar 23 2017
,
Apr 14 2017
,
Apr 18 2017
Part of issue 635699 is to make the avatar button the same height as the caption buttons. I'm currently using GetSystemMetrics(SM_CYSIZE) for this (not yet committed), but the result isn't quite right for all scale factors. See MinimizeButtonMetrics::GetMinimizeButtonHeight().
,
Apr 28 2017
,
May 5 2017
In 718590#c2 a user reported that the omnibox right border isn't pixel-aligned at 125% scaling. Double-check that this is fixed when everything is snapped to pixels.
,
Aug 22 2017
,
Dec 14 2017
Pixel canvas should solve majority of the pixel positioning bug. It is currently enabled by default on CrOS.
,
Mar 28 2018
,
Nov 21
**UI Mass Triage** Adding labels for expert review. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by bsep@chromium.org
, Nov 23 2016