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

Support for physical vs logical pixels #22

Open
glenmurphy opened this issue Jul 9, 2022 · 5 comments
Open

Support for physical vs logical pixels #22

glenmurphy opened this issue Jul 9, 2022 · 5 comments
Labels
enhancement New feature or request Needs Design Work

Comments

@glenmurphy
Copy link

glenmurphy commented Jul 9, 2022

On macOS, the buffer is applied using logical pixels rather than physical pixels so a 100x100 buffer will fill a 100x100 (logical pixels) window even if the window occupies 200x200 (physical) pixels. A 200x200 buffer in the same scenario will just be cropped. This is a good default that makes UI easier to develop, but results in output that looks low res.

I'm currently working around this by setting my buffer to the physical pixel size, then scaling it on application by adding the following to set_buffer in cg.rs:
self.layer.set_contents_scale(width as f64 / self.layer.bounds().size.width);

I'm not sure what the right and real mechanism for doing this should be (e.g. always use physical? allow scale factor choice?)

@LoganDark
Copy link

LoganDark commented Jul 24, 2022

Softbuffer always (should always??) uses physical pixels. Your issue is that macOS is scaling the application because it doesn't know it supports HiDPI. You have to find the binary in Finder, Cmd+I on it, and uncheck "Run this app in low-resolution" (or something like that). This should be remembered across builds.

The actual solution to this problem is to use something like fruitbasket to run the app as a bundle, which can include a plist that tells macOS it supports HiDPI.

@tronical
Copy link
Contributor

I think that this should not be worked around in the application, softbuffer should apply the contents scale factor to the layer it creates as if the application rendered it by hand. I've made a PR for this.

tronical added a commit to slint-ui/slint that referenced this issue Dec 13, 2022
@LoganDark
Copy link

I think that this should not be worked around in the application, softbuffer should apply the contents scale factor to the layer it creates as if the application rendered it by hand. I've made a PR for this.

Absolutely, I agree.

tronical added a commit to slint-ui/slint that referenced this issue Dec 13, 2022
john01dav pushed a commit that referenced this issue Dec 22, 2022
@john01dav john01dav added enhancement New feature or request Needs Design Work labels Dec 23, 2022
@jackpot51
Copy link
Member

jackpot51 commented Jan 6, 2023

I pretty strongly believe that the conversion from logical to physical should happen in the consumer of softbuffer, and that softbuffer should always present physical pixels.

@LoganDark
Copy link

I pretty strongly believe that the conversion from logical to physical should happen in the consumer of softbuffer, and that softbuffer should always present physical pixels.

exactly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Needs Design Work
Development

Successfully merging a pull request may close this issue.

5 participants