lite
lite copied to clipboard
rxi
Runs on OSX 10.15.4 but screen resolution is low or very zoomed in
There is a possible fix on a HN comment here: https://news.ycombinator.com/item?id=23127110
@bin It worked - thanks! See new attachment.
src/main.c
changed:
static double get_scale(void) { float dpi; SDL_GetDisplayDPI(0, NULL, &dpi, NULL); #if _WIN32 return dpi / 96.0; #elif APPLE return dpi / 192.0; #else return 1.0; #endif }
@euvl It requires SDL2, so you will need to install it, if not already. Can be as simple as brew install sdl2
The core issue here isn't the scaling factor being resolved by lite, but rather the fact that it's not registering as a highdpi application and as a result is being scaled up by OSX. On windows the SetProcessDPIAware function is called to set high dpi mode, I've researched this in the past and couldn't find a simple OSX equivalent.
I don't personally run OSX which is why it isn't listed as a supported operating system, despite having some support. I won't personally be looking into this further as it makes little sense for me to maintain the project and develop for a platform that I don't use and have no means of testing on -- if someone else manages to fix this in a reasonable manner I'd be happy to accept a pull request!
As a work-around lite can be forced to run at a scaling factor of 1 by setting the LITE_SCALE environment variable to 1
From using SDL in the past, I remember being able to set the SDL_WINDOW_ALLOW_HIGHDPI flag in SDL_CreateWindow(). That might fix it?
Sorry, I replied on my phone and didn't bother to check that first 😅
What I did find is that you have to stick the application in a .app, and add an Info.plist with NSHighResolutionCapable set to true.
@SijmenSchoon do you mind sharing how you created/structured your .app bundle?
I was looking to fix this, which turned out into me rewriting the entire renderer.c to use SDL_Renderer. This fixes the problem. I have yet to clean it up and test it on other platforms, but would you be open to a pull request for this @rxi ?
I would not be open to merging that change @SijmenSchoon -- I'm also surprised by the fact that there was no easy-enough-way to enable this that you had to go to such measures. If these are the lengths required to get lite working reasonably on OSX it may be worth forking the project into something that's tailored more towards it, such a fork could have better support of command and option in place of ctrl and alt, too
For the mean time I've pushed a commit so that lite always resolves to a scaling factor of 1.0 on OSX, not at all ideal, but this way it at least hopefully renders at the correct size.
Is there any specific reason why you would be against using SDL_Renderer, opening up ways to hardware acceleration and overall being a more SDL-idiomatic approach? As in, was there a specific motivation behind implementing the rendering routines yourself?
I imagine all platforms benefit from a change like this, not just macOS.
EDIT: You can look at the changes here: https://github.com/SijmenSchoon/lite/blob/master/src/renderer.c (the commit) - it is in no way optimal yet, I've just bashed it into shape until it works. If some more time is put into this, it can be much more elegant.
Also I'd like to add the side note that, while I do own a macOS device, it is not my daily driver and I'm not willing to maintain a fork for macOS support.
@SijmenSchoon The current software rendered approach is in line with the projects goal's of simplicity. Note that I appreciate the efforts that you've put into getting the highdpi mode to work on osx, but the extremity of the change does make it conflict with what I had in mind for the project.
Additionally the fork suggestion was meant sincerely, the way it's looking is that to get lite running well on osx it may require more of these kinds of changes, and is not something I'd be able to do myself -- I'm not suggesting that it's in any way your responsibility to do it, rather that a lite-osx fork might not be a terrible idea if someone feels inclined.