softbuffer
softbuffer copied to clipboard
Support for physical vs logical pixels
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?)
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.
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.
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.
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.
I pretty strongly believe that the conversion from logical to physical should happen in the consumer of
softbuffer
, and thatsoftbuffer
should always present physical pixels.
exactly