[haiku-development] Re: app_server 4k and more implementation
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 06 Oct 2014 16:32:18 +0200
Hi,
Am 06.10.2014 14:33, schrieb Axel Dörfler:
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,
I've read this before, and it might be how it is currently implemented,
but from reading the docs, I am pretty sure the API does not use pixels.
http://docs.oracle.com/javase/7/docs/api/java/awt/Graphics2D.html:
In the introduction:
"All coordinates passed to a Graphics2D object are specified in a
device-independent coordinate system called User Space"
and
"The scaling of the default transform is set to identity for those
devices that are close to 72 dpi, such as screen devices"
"Point" is a unit where there are exactly 72 per inch.
that wasn't really what Alex was talking about anyway :-)
Maybe I misread.
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.
Indeed.
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 am not sure. Right now, you use a coordinate system to tell app_server
where to draw things. The coordinates mean pixels. If you just change
the meaning of the coodinates to mean points, and use a fixed mapping
between points and screen pixels, nothing changes for the application in
terms of specifying where and how large things are supposed to be
relative to each other.
Of course you need to be able to change the scale or effective
transformation (as you already can). And you need to be able to get
information about device resolution (from the screen or the printer), so
that you can still target invididual pixels, if you need to. You would
do that by setting up the transformation so effectively you have a 1:1
mapping between coordinates and pixels.
I would try to implement this completely in the component/widget/view
classes.
How exactly? By having a default scale in the initial graphics state?
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.
Apple uses a concept where an Image has multiple "representations" and
the screen uses the best fit.
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).
But that will not work. I don't want to go modify each app. If you
follow my proposal, if an old app creates a BBitmap and it defaults to
72 DPI, it will draw in it as before, with a 1:1 mapping from
coordinates passed to BView functions to pixels of the bitmap. It will
also be consistent with when it modifies pixels directly. And when the
BBitmap is rendered, the coordinate mapping of the BView drawing it
would result in a scaled bitmap on screen. That is heaps better than a
bitmap which is too small, and also heaps better than having to modify
all apps. And it was good enough for Apple.
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.
An option to have all custom controls half their sensible size? It
doesn't make sense to me.
I guess it shouldn't be too hard to come up with a proof-of-concept
implementation for that approach.
Neither would it be hard to write a proof-of-concept for what I proposed.
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 would target the case of one attached screen first. Then after we have
buffered windows some time in the future, we could render the window in
two scalings if it is spread over two screens.
Best regards,
-Stephan
Other related posts:
