FLTK logo

[fltk.coredev] Re: RFC: API for screen sizes on mobile devices

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC: API for screen sizes on mobile devices "'melcher.... Sep 02, 2020  
 

Manolo schrieb am Mittwoch, 2. September 2020 um 11:38:20 UTC+2:
On Wednesday, September 2, 2020 at 10:21:58 AM UTC+2 Matthias wrote:
...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"?
Yes, the hardware composites the screen content from 8 or so layered hardware buffers, each one can be scaled arbitrarily.
  
In that case, the developer must respect the width/height ratio of the display.
Yes, pixels must always be square. You would only set the WIDTH *or* the HEIGHT, and the driver would calculate the rest.

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_ONLY);
Fl::hint(FL_MOBILE_DEVICES, FL_SCREEN_LANDSCAPE_WIDTH, 1024);

Device: MOBILE, DESKTOP, ...
I'm not sure to understand that line.
Sorry, too abbreviated. There could be different hints for different host types. For example:
Fl::hint(FL_MOBILE_DEVICES, FL_APP_FULLSCREEN);
Fl::hint(FL_DESKTOP_DEVICES, FL_APP_WINDOWED);
 
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?
 
Imagine old CRT displays. You could request 800x600 mode or 640x480, or whatever, and it would always fill the entire screen. By keeping Fl::screen_scale() to 1.0 and having the Android compositor scale the screen in real time, we can make life quite easy (and fast). 


--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/267b6aa2-3fbc-4a40-b618-a5a89338cbaen%40googlegroups.com.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.