Closed curlywurlycraig closed 3 years ago
Hang on, I just noticed that if I zoom into that window, the screenshot is showing 1 pixel for each line 🤔
Ah yes. It appears to be two pixels wide, not one. As if what we actually need is a 0.5X scaling factor. I still suspect this is related to the change to using Metal.
If you set WindowOpts to something like
WindowOptions {
scale: Scale::X2,
..WindowOptions::default()
},
Does it seem to look better?
That makes it worse (4 pixels for every real pixel):
Ok, doubling of pixels is expected (that is the point of the scale factor) but not sure about the need for 0.5X scale and I doubt it's related to Metal. I just thing it's because minifb doesn't do anything special for HiDPI. It would be interesting to know if it looks correct if you set macOS to non-scaled mode.
The problem remains when I use default for display. If this isn't related to Metal, is it possibly something in the Cocoa window management code? I don't know much about Cocoa unfortunately, so I can only get so far trying to debug this myself.
I see. I will have to look into it at some point, but currently I don't have easy access to my mac so I can't do it for a while.
Sure. Thanks for your help
All you have to do is multiply the width and height of the buffer (but not the window) by two. This is intended behavior and minifb is working correctly.
Watch out for #221. minifb currently offers no facilities for actually determining what the scale factor is.
Makes sense, thanks.
Being tracked in #236
Description
With a retina display Macbook (Mojave, mid-2014, 13"), it is as if retina is not being used.
With the following code:
I see the following result:
when I would expect the lines to be 1 pixel wide every time.
I wonder if this is related to changing to use Metal.