Cross-Platform Windowed Graphics Surprises with Hi-DPI

A few weeks ago, I learned that some cross-platform native graphics API work very well with 1080p resolution but do not have the best support for 4K display resolutions when it comes to font rendering. Granted, some of the major API of this kind handles this well. API like Qt, wxWidgets, and a few others that I’ve read about were updated to handle the upcoming wave of pixel resolution possibilities.

I created the first version of a software application in 2015 using a native graphics API. It does what I need it to do and met all my implementation goals. However, the stable version of the API upon which it is based was not ready for high-DPI. That API is Fast and Light Toolkit (or FLTK). A solid API that is well-defined but the high-DPI support is none-existent.

A few of the articles I read on the subject of high-DPI in FLTK suggests that the dpi in FLTK is hard-coded to 96dpi. FLTK is open-source and so I went into the actual source code of FLTK for the first time (I was using at an application level all this time) and looked at the way it handled dpi calculations. Version 1.3.3 has some dpi calculation but it does not take effect. In the source code file, screen_xywh.cxx, there is a comment on line 161 about rewriting the screen_init() function with RandR.  I briefly /*commented out*/ lines 174 – 177 and lines 192 – 195 and replaced them with a generic dpi calculation that produced the correct dpi value but did not override the FLTK system determined dpi of 96. Rather than debug that further and face the prospect of having to maintain that, I decided to look around at other solutions.

After much thought, I settled on Glfw at first. I liked the writeup on their homepage, especially the part about high-dpi support. As well, I saw that the Glfw API handles input and a few other things. I coded up the basic example you see at the end of this page. I works well and their API functions as advertised. A desirable aspect of this API is that it compiles clean and proper with C++14. That is one of the reasons I decided not to go with wxWidgets. wxWidgets was my first choice consideration after FLTK. I read the wxWidgets book on Amazon 8 years ago, but it is an API that does not keep pace with the latest C++ evolution. That is not such a bad thing, especially if you are striving for reliability and consistency. However, in personal projects, I strive for the latest in C++ compiler support. The Glfw API is nice and handles that aspect well. After more time with it however, I decided it also was not quite what I was looking for (or needed). I foresaw a drop in productivity compared to FLTK so I looked for something with the capabilities I could have with Glfw but with some productivity aspects that I could move things along a little more quickly from a code standpoint. I decided to go back to Allegro which I last used 4 years ago. It seems to have improved considerably since the last time and so I am going to give Allegro 5 a try.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s