On Wednesday, September 2, 2020 at 10:21:58 AM UTC+2 Matthias wrote:
I am hoping for a good idea to manage screen size on Android. The physical resolution and density can be pretty much anything (for example, the Galaxy Note 10 Plus has 6.8-inch at 3040x1440 pixel), but apps are often written for a fixed scale and can request a different pixel buffer resolution that is then scaled up by hardware at screen refresh time.
Does that mean "the developer writes the app for a pixel size s/he decides, and the hardware efficiently scales the
bitmap produced by the app to the true display size"?
In that case, the developer must respect the width/height ratio of the display.
Also, there should be an API to limit apps to landscape or portrait mode.
I was thinking about something like:
Fl::hint(FL_MOBILE_DEVICES, FL_SCREEN_LANDSCAPE_WIDTH, 1024);
Device: MOBILE, DESKTOP, ...
I'm not sure to understand that line.
Screen: LANDSCAPE_ONLY, PORTRAIT_ONLY, LANDSCAPE_WIDTH/HEIGHT, PORTRAIT_WIDTH/HEIGHT, ...
Is the intention to use only WIDTH or only HEIGHT, and infer the other dimension considering the hardware display size?
Isn't an API to get the hardware width/height ratio necessary?
This API avoids #ifdef __ANDROID__ and can be extended later without breaking the ABI. Unsupported hints are simply ignored.
Using Fl::screen_scale() is similar in that it would allow super high resolution rendering on Android, but it would use up a lot more resources (time and energy), and may slow down rendering considerably.
Does that mean "FLTK builds a bitmap the size of the display hardware, but transmits scaled units to the FLTK user. Just like
under Windows on a HighDPI screen."?
Is it sure this would be slower, since no bitmap scaling should be performed?
What do you think?