I’ve written up a specification for this Glk extension, please take a look:
Can anyone think of any issues with how it’s specified? Is simply multiplying the ratio by 1000000 and returning it as an integer going to be accurate enough?
It’s pretty simple so if there aren’t any issues then I’ll probably implement it and add it to Parchment this month.
Oh, there are always issues with DPI scaling! 
Minor first thought: calling it “pixel ratio” makes me think of the ratio between a pixel’s width and height (like the tall pixels in some video modes on the Commodore Amiga, if you’re old enough for that), or the ratio between screen width and height (like 4:3 versus 16:9 TVs). Possibly call it something else, though exactly what I am not so sure?
Second thought: at least on Windows, if you have the scaling set to 150%, it’s not the case that what your spec calls “virtual pixels” is the default. In a Windows app with the correct manifest (as used by Windows Glulxe and Git) then the app will see the “correct” physical screen width and height as measured in pixels. So saying that virtual pixels, representing some nominal “default” resolution, is the default would really be significant change from current behaviour.
I don’t have good answers for any of this, of course. I suspect if needs to be as simple as possible for the game author, along the lines of the game declaring “I have been made to look good at (say) 1024x768, do what you have to to make it look good at other resolutions” to the interpreter.
Haha, oh no! Definitely no non-square pixels anywhere near me please!
I called it “pixel ratio” because the web browser interface is called devicePixelRatio, so I thought some people might already be familiar with it. I’d expect more people would be familiar with it than non-square pixels! But if anyone can think of a better name I’d be happy to change it.
Ahh, interesting. Browsers do turn the Windows screen scaling setting into a devicePixelRatio, so that’s why I thought that 150% Windows scaling would represent a 1.5 ratio.
But… when I dragged a Windows Git 1.3.7 window from a 100% screen to a 150% screen, the window was expanded rather than displayed at the same physical size. However testing various games with graphics it does appear that Windows Glk does use a 1:1 ratio. So text is displayed at a 1.5:1 ratio, but graphics at a 1:1 ratio. To be honest, that’s not a scenario I imagined. It doesn’t make much different when the ratio is small, but if it got up to 300-400%, as someone might want to do with a 4K screen that they don’t view close up, then the graphics will appear very small. To be honest, I’d suggest you consider changing Windows Glk’s behaviour…
It’s hard to see how the behaviour would change in a way that would be unambiguously better. Fonts are specified in terms of point size, which is why going to a 150% display makes the font bigger. But if a graphic is drawn in a text buffer at full size, scaling that up by 150% looks just horrible. This sort of thing is why all these high DPI issues are hard to solve.
Yeah it is difficult. If we can’t come to a rough consensus then I think it would be better not to actually add this extension.
But that said, this feels a little like the confusion in how different browsers used to implement zooming: IE and old Safari would only zoom text, while Firefox and Chrome would try to zoom the whole page. Over the past decade browsers have converged on zooming affecting everything, while exposing devicePixelRatio for apps to be smarter if they want. (Zooming does change the devicePixelRatio, so it’s a very similar situation to changing monitors.) In a browser if an image is displayed at full size then it may be upscaled (possibly becoming more blurry), but if displayed at less than full size then depending on the zoom/pixel ratio it may end up being displayed at true full size or even downscaled (which is typically less bad than upscaling.) Despite upscaling being very common on the web (particularly on phones) it doesn’t seem like most people actually mind much at all.
And just like for the web, people are now discussing about intentionally using larger images in IF games in case the interpreter is a high-DPI one (displaying them at half size with glk_image_draw_scaled rather than glk_image_draw). The whole situation is very similar to the web, and not just for the web-based interpreters!
When I added high-DPI support to Parchment I wanted it to work like browser do, not just because it would be simpler to base what Parchment does on what they already do, but because I think the way they work is sensible. The only missing part was the ability to expose the pixel ratio to the game so that it could do something more advanced if it wanted, like a web game that uses a <canvas> with native physical dimensions rather than CSS pixel dimensions to ensure its drawings are sharp.
That’s part of why I suggested this extension, so that the “true” size of an image (in pixels) wouldn’t have to be important.
I agree that the web does seem to have settled on a model for different resolutions that, while perhaps not ideal, is often good enough. But what it boils down to is that in effect, most web sites are now specifying that images are drawn at a particular size (expressed in logical units or pixels), irrespective of what the actual image size is. While in the Glk world, most images are shown by the game really just saying “show this image”. Until we have a model where images are generally shown with some metric to say approximately what their size should be in some sense, we aren’t going to get anything as successful as the web for all this.