[haiku-development] Re: app_server 4k and more implementation

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 06 Oct 2014 14:33:43 +0200

Am 06.10.2014 09:38, schrieb Stephan Aßmus:
Am 06.10.2014 um 00:35 schrieb Alexander von Gluck IV
<kallisti5@xxxxxxxxxxx>:
I think maybe going "dpcm" is a better idea (metric)
(http://en.wikipedia.org/wiki/Dots_per_centimetre)
I would like to stick to the unit „point“, which is a well
established typographic unit. It doesn’t really matter how big a
"point“ is in another unit, be it cm or inch. There are several big
APIs which use point, Cocoa and Swing are two examples that I know
of. And font sizes were specified in points for ages.

While I'm pretty sure that Swing uses plain old pixels, that wasn't really what Alex was talking about anyway :-) dpi vs. dpcm is just cosmetic, but I would prefer to use dpi as that is pretty much standard, and you can easily convert it if you're so inclined.

I’ve chatted with Jonathan a bit about this, we
thought BBitmaps could get a resolution parameter which defaults to
72 DPI (i.e. a 1:1 mapping of points to pixels).

Not sure if that improves things. Having all elements use the same on-screen size is only half of the solution, as you also want to be able to actually change the size things have on-screen. Pre-rendered bitmaps definitely need to use the on-screen resolution, while other bitmaps (such as icons) will have to be scaled. IOW we always need to have both options around.

I would try to implement this completely in the component/widget/view classes. As a user you would still be able to specify your font sizes as usual, plus force a system wide magnifying factor (this would default to take the actual screen size into account to have the elements the same real size). You can set different font sizes per view anyway, and you could have different zoom levels per screen. The biggest change this would mean is that windows may have to be resized/relayouted on screen change, and that you couldn't have one window occupying space on two screens at the same time.

If you use our own widgets and the layout functions, everything would always look like it should. If you draw bitmaps yourself, you have to solve the issues yourself (we should have some utility class for this, of course, that is used everywhere internally).

We could have a system-wide setting for legacy apps that would either cause all windows to be non scaled or scaled. Our own controls would look the same either way, only custom controls, window sizes and drawings would be scaled.

I guess it shouldn't be too hard to come up with a proof-of-concept implementation for that approach.

AFAICT, if we wanted to show the same window on differently scaled screens at the same time we would need to give up font hinting (by drawing everything as vectors). Of course, one could always have a base scale for a window, and rescale everything that is on a different monitor (losing hinting and with unsharp bitmaps). Not sure if that would be any better than to give up on the idea at all, though :-)

Bye,
   Axel.

Other related posts: