Font sizes off

[mbillingr]

Finally managed to run this on my Notebook (Arch Linux, Intel graphics), which did not work before because of a bug in Mesa.

Now the fonts are rendered too big. This needs investigation.

Todo:

• [x] are other systems affected too?
  • This does not happen on my other Arch Linux machine

[icefoxen]

This is interesting. If your notebook has a highdpi display (something bigger than 1080p) there might be an extra scaling factor involved, and it might be getting taken into account incorrectly in calculating the font sizes. Does toggling WindowSetup::allow_highdpi change anything?

[icefoxen]

On my (non-high-dpi) laptop running Debian Linux (with Intel GPU), the fonts are not as big as they are for you but still look too large.

Also I see artifacts in both that look a lot like https://github.com/ggez/ggez/issues/302 , annoyingly. I wasn't able to reproduce that before...

[mbillingr]

The display resolution is 1920x1080... not sure if that counts as high dpi. :) Setting allow_highdpi to true or false does make no apparent difference.

Is font rendering somehow dependent on screen resolution? "Higher resolution -> larger fonts" would make sense if I was not using a fixed window size...

Another observation: Windows OS seems unaffected. Fonts have the intended size on the notebook when running on Windows (I compiled on another machine, but don't want to believe this has anything to do with it.)

[icefoxen]

No, 1920x1080 doesn't count as high-dpi. The whole concept is something of a hack for letting applications that assume 1920x1080 pretend to work well on higher resolution screens.

ggez tries to scale fonts based off the DPI of the display, which is reported by the OS. So, different OS's may report different things. It's kind of a pain in the butt all around, so that's what I suspect is the cause. :-/ winit at least gives us more information about what the heck is actually going on, so hopefully that will improve in the next version... I'll dig more into the DPI stuff in 0.4.3 and see what I turn up.

Of course my theory could be wrong, so. Easier way would be to instrument the ggez code to print out a bunch of info about what size text it's actually creating and why. Easy enough to do; just check out the master branch and add some println!()'s to Font::new(), display_independent_scale() and render_ttf(), then build solitaire using that version of ggez. Here's what it prints out for me:

DPI: 75, 75 [this is for the default font, which is created before we can really get DPI info]
points: 16
Font scale: Scale { x: 16.666666, y: 16.666666 }
Loading font "/glacial/GlacialIndifference-Bold.ttf"
DPI: 140.94798, 141.40207
points: 25
Font scale: Scale { x: 48.94027, y: 49.09794 }
Loading font "/glacial/GlacialIndifference-Bold.ttf"
DPI: 140.94798, 141.40207
points: 42
Font scale: Scale { x: 82.21966, y: 82.48454 }
Text width pixels: 13, text height pixels: 50
Text width pixels: 21, text height pixels: 50
[...]

[mbillingr]

This is what I get:

  scale: Scale { x: 16.666666, y: 16.666666 }
Font::new()
  name: "/glacial/GlacialIndifference-Bold.ttf"
  points: 25
  DPI: 174.17143, 171.45
  scale: Scale { x: 60.47619, y: 59.531246 }
Font::new()
  name: "/glacial/GlacialIndifference-Bold.ttf"
  points: 42
  DPI: 174.17143, 171.45
  scale: Scale { x: 101.6, y: 100.0125 }
width_pixels: 16, height_pixels: 60
width_pixels: 26, height_pixels: 60
[...]

Looks like the text size scales rather nicely with the reported DPI.

[icefoxen]

Right, now check what DPI's get reported by Windows...

[mbillingr]

ok... that will take a while, though. I have to set up a toolchain first :)

[mbillingr]

That's the Windows result:

  scale: Scale { x: 16.666666, y: 16.666666 }
Font::new()
  name: "/glacial/GlacialIndifference-Bold.ttf"
  points: 25
  DPI: 96, 96
  scale: Scale { x: 33.333336, y: 33.333336 }
Font::new()
  name: "/glacial/GlacialIndifference-Bold.ttf"
  points: 42
  DPI: 96, 96
  scale: Scale { x: 56.0, y: 56.0 }
width_pixels: 9, height_pixels: 34
width_pixels: 14, height_pixels: 34

Exactly the same DPI values are reported on both my notebook and the PC.

[mbillingr]

In summary:

DPI reported	Linux	Windows
Notebook	174.17 x 171.45	96x96
PC	81.55 x 81.64	96x96

[icefoxen]

Well, we have solved PART of the mystery! We know "what", just have to figure out "why"...

Edit: Or on ggez 0.4.3 at least, you can use Font::new_px() to just bypass the whole DPI nonsense. Trying to do things the "right" was often leads to inconvenient results, no?

[mbillingr]

The DPI values reported by Linux seem plausible, at least. I wonder if the Windows values are some "sane default they report to make it easy for developers" or a limitation of winit. Sometimes it may be more effective to take the simple path instead of the right one :)

new_px() sounds like it fits my bill very well. I will give it a try these days. Perhaps it would make sense to have it as the "default" Font::new() function in the distant future? I (rather subjectively) tend to think that most games need to scale fonts to match fixed-size pixel art rather than the monitor resolution.

Is there anything I can do to help?

[icefoxen]

Well for ggez 0.5.0 we use gfx_glyph for text drawing and winit for DPI querying, instead of rusttype and sdl2 as used by 0.4.0. So the stack has changed and the API for dealing with it is still under development. Pixel-sized fonts are definitely going to be a priority though.

[mbillingr]

The new_px() was easy enough to transition to, and seems promising so far. I still have to make sure it's consistent across system (but would be surprised if it wasn't). So I consider the issue as good as solved from my side.

Thanks a lot for the support and for engaging in discussion! I'd like to contribute back to ggez at some point, but currently I have no idea what I can do that's needed :) Will keep a lookout for issues, though.

[icefoxen]

Contributions are always welcome! Writing things using ggez and talking about them is a pretty good way to contribute. ;-) So is writing add-on libraries if there's features ggez lacks that you can implement on top of it. (GUI libraries and better bitmap fonts using SpriteBatch are perennial requests.)

Apart from that, depends on what you like doing. Simple stuff like testing on different platforms and reporting bugs makes a huge difference, tbh; there's only so much time I can spend on testing, and my selection of hardware is limited. I've tried to start marking issues that are easy to get started with again, so take a look at that. Writing handy examples are also nice, especially in working with 3rd-party libraries like specs or ezing.

RIGHT NOW, two easy things that really need work are a) updating the audio API be nicer and use more modern rodio features (something you might know a thing or two about), and b) updating/clarifying the examples to work with the current 0.5.0 devel version.

[mbillingr]

I don't really know that much about rodio or audio programming, but actually this is something I would not mind diving into. Now that my appetite is whetted I'll do some research on the libraries. If there is anything I think I can do, I'll open an issue at ggez :)