[haiku-development] Re: app_server 4k and more implementation
- From: Ralf Schülke <ralf.schuelke@xxxxxxxxx>
- To: haiku-development <haiku-development@xxxxxxxxxxxxx>
- Date: Mon, 6 Oct 2014 15:53:21 +0200
2014-10-06 14:33 GMT+02:00 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> 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 :-)
I prefer we start on dev.haiku-os.org a page and work on a defination
of work of concept.
I think we need some stuff:
1.) display he are not 4k and more, need what we have now
2.) display up to 4k, have automatlicy pixel to dip render
3.) setting on screen preferences the reder automatically or legacy
4.) rdef need some non-auto scale resources, how can put the bitmaps
(png, jpg,etc) or a path to file/folder
5.) some privat helper class for calc pixel to dip, calc scale
bitmaps, defaults bootstraps for rdef (see 4)
To 5.
i can have more bitmaps for every size.
px/mylogo.png -> normal size
hdip/mylogo.png -> hd size
udip/mylogo.png -> ultra dh size
...
all other images scale automatically
>
> Bye,
> Axel.
>
stargater
Other related posts:
