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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 7 Oct 2014 17:51:14 +0200

Hi,

Am 07.10.2014 um 10:17 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> Am 06.10.2014 16:32, schrieb Stephan Aßmus:
>>> 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.
> [...]
>> "The scaling of the default transform is set to identity for those
>> devices that are close to 72 dpi, such as screen devices"
> 
> Isn't that how the Be API works, too? When printing, we use a different 
> resolution (and even sub-pixels), too.
> The outcome is the same: on screen devices, you always have a 1:1 mapping

I have to re-read the chapters on printing. But from what is still in memory, 
you pull the printers drawable BRect frame and fill it. You may record your 
BView drawing in a BPicture and play that when printing. I need to read up on 
who exactly is responsible for scaling the BPicture, or if there is perhaps a 
scale already applied when your BViews Draw() method is called for printing.

>> 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.
> 
> That's only partially true: when you use (font) hinting, the sizes don't 
> scale linearly but more or less arbitrarily.

Yes, hinting should be used, or the point to device pixel scale should perhaps 
always be an integer (as if the screen had a multiple of 72 DPI, like Apple 
does it). But even if that isn’t the case, I guess hinting would always effect 
the position of individual coordinates according to the current pen size. Hey, 
that is actually what happens already when you don’t specify B_SUBPIXEL_PRECISE 
as a BView flag. So the relative position and size of things is not affected 
much at all. Less so for increasing scales. At least I don’t see why this 
„problem“ would be a concern for any design decision.

>>> 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?
> 
> For example, but each view would do that manually. Since we may want to hint 
> the lines, too, that would probably be done manually, though (without a scale 
> in the state).

I don’t think this is a good idea. The app_server knows the DPI of the 
rendering surface. And it is actually a good idea to provide BBitmaps with a 
DPI property, the Translation Kit is actually missing this crucial information 
when storing images.

What happens when you remove a BView from a BWindow, place it in a BBitmap and 
have it draw? Wouldn’t it be nice if all drawing calls where in a device 
independent coordinate system, and the scaling happens where the actual drawing 
is implemented, according to the current device target?

And I don’t see how you can make clients responsible, but have old clients 
magically work. What you have to do for those old clients is exactly what you 
can do for the current and new clients as well. So why not go that way from the 
start?

All I know is that point based drawing APIs are incredibly convenient for the 
common case. Our SWT based Java app "just works" on Retina Macs (minus /some/ 
images, which are scaled). On Windows, a lot more work is needed to get it to 
behave correctly.

>> Apple uses a concept where an Image has multiple "representations" and
>> the screen uses the best fit.
> 
> Sure, we could do that, too, in a BBitmapView, resp. BView::SetBitmap().
> I don't think it's a good idea to put that logic into BBitmap itself (rather 
> invent a new class for this).

It’s much better to wrap the concept into a new class, BImage perhaps. 
Otherwise you would force one BView per bitmap to use the feature. And it may 
be handy outside of BViews.

>>> 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.
> 
> You wouldn't need to do that. Applications using the layout kit would just 
> work. Legacy applications would use actual scaling.

Why provide the convenience only to legacy apps?

>> [...] 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.
> 
> Apple doesn't use font hinting.

Why does that matter in the discussion?

> Of course, if your resolution is high enough, you don't need it, but it will 
> look bad on regular screens. In a few years that won't matter, of course, but 
> it does now.
> There is a reason why Windows chose a different path here, and I think what I 
> suggested goes into that direction, too. While it has its downsides, it will 
> allow for sharper fonts.

The Apple solution works incredibly well. The Windows solution arguably not. I 
think having only integer scales is sensible, even when screens come in many 
different physical resolutions. What looks good for a user is a factor of many 
things. The viewing distance, comfortable font size to read. But the rest of 
the graphics will only look good when the scale is an integer.

>>> 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 don't understand what you mean.

I mean, why provide an option for something that no one will want (custom 
controls that are half of the sensible (and intended relative) size).

Best regards,
-Stephan


Other related posts: