Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Divider line thickness not consistent at 150% scale #2231

Closed
adkaufm opened this issue Sep 9, 2019 · 8 comments
Closed

Divider line thickness not consistent at 150% scale #2231

adkaufm opened this issue Sep 9, 2019 · 8 comments

Comments

@adkaufm
Copy link

adkaufm commented Sep 9, 2019

The thickness of the Divider component is not consistent when the page is scaled to 150%.

  1. Go to https://explore.fast.design/components/context-menu
  2. Add two dividers to the context menu using the "children" menu
  3. Zoom in the page to 150% or set your windows scale factor to 150% in Windows settings
  4. Observe that one divider line appears to be 2 pixels wide, while the other is only 1 pixel.

I would expect that the thickness would always be exactly one pixel.

image

This issue is observed on Windows in both Chromium-Edge and retail Chrome. It seems to be a renderer bug, but I found a fix that works. Setting the border width to 1/window.devicePixelRatio makes the line always 1 pixel. However this has to be done at render time because devicePixelRatio might change.

Overall, I'm not sure it makes sense to fix this in the fast component. Please let me know what you guys think. Maybe providing a utility function, or adding a prop like adjustForScaleFactor or something.

@triage-new-issues triage-new-issues bot added the status:triage New Issue - needs triage label Sep 9, 2019
@chrisdholt
Copy link
Member

Thanks @adkaufm - Ideally I'd love this to get fixed on the rendering side of things, but that can obviously be complex. Do you know if this repro's at all in non-chromium browsers? My immediate thought is in scenarios where this is important a user can always pass the style in as an unhandled prop which would cause it to inline to the DOM and take precedence.

Pinging other @microsoft/fast-dna-collaborators for their thoughts on the above as well.

@triage-new-issues triage-new-issues bot removed the status:triage New Issue - needs triage label Sep 9, 2019
@adkaufm
Copy link
Author

adkaufm commented Sep 9, 2019

Right - I added the fix with an unhandled prop every time we use Divider. And I agree that a fix on the renderer would be ideal here. I just thought to raise the issue here given that Chrome is such a big share of the market. And keep in mind many devices are automatically at 150% scale (surface products for example), so it will repro a lot.

@chrisdholt
Copy link
Member

Right - I added the fix with an unhandled prop every time we use Divider. And I agree that a fix on the renderer would be ideal here. I just thought to raise the issue here given that Chrome is such a big share of the market. And keep in mind many devices are automatically at 150% scale (surface products for example), so it will repro a lot.

For sure, I think this is a valid scenario and worth the conversation.

@eljefe223
Copy link
Contributor

Edge:
image

Chrome:
image

Safari: (no Repro)
image

Firefox: (no Repro)
image

@chrisdholt
Copy link
Member

@adkaufm there could be an interesting experiment here. What would happen to all FAST components if we set the design system system value for certain things to a value derived from window.devicePixelRatio? I think we'd need to look at similar things, but outline width, and focusOutlineWidth are two that come to mind. It could be an interesting experiment to see if that would help or hurt the issue we're having with subpixel rendering here.

@bheston for awareness

@stale
Copy link

stale bot commented Dec 8, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the warning:stale No recent activity within a reasonable amount of time label Dec 8, 2019
@chrisdholt chrisdholt added the status:needs-information This issue needs more information label Dec 16, 2019
@stale stale bot removed the warning:stale No recent activity within a reasonable amount of time label Dec 16, 2019
@stale
Copy link

stale bot commented Mar 15, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the warning:stale No recent activity within a reasonable amount of time label Mar 15, 2020
@EisenbergEffect EisenbergEffect added area:react and removed discussion status:needs-information This issue needs more information warning:stale No recent activity within a reasonable amount of time labels Jul 17, 2020
@chrisdholt
Copy link
Member

closed with #3517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants