[PATCH 0/2] Support for high DPI outputs via scaling

[Alexander Larsson]

On tis, 2013-05-14 at 07:11 +0200, John Kåre Alsaker wrote:

>         
>         While this isn't a huge problem on GL-based compositors it
>         will cause a problem for software compositors.  Any scaling
>         for that matter is a potential problem there.  However, a
>         factor of two or something shouldn't be too bad in software.
>         
> Compositors do not have to scale anything at all. Even with fractional
> scaling factors a compositor could limit itself to just scaling with
> integer factors. I don't think software compositor is a case worth
> considering either. Nobody wants to have those, especially with
> high-DPI displays.

I don't think it should really be allowed to not apply the scaling.
Right now buffer sizes define surface sizes, and that makes surface
sizes not really well defined. For instance, if you maximize a surface,
or resize it you will get a configure request with a surface size
specified. You then want to make your surface that size, so you create a
buffer with that size, scaled by the factor you pick. If the compositor
chooses not the given factor but rather a somewhat smaller one then your
surface will be larger than expected, and extend outsize of the monitor
in the maximized case, or not hit the pointer in the drag resize case.

Also, it makes surfaces different sizes on different monitors. If an
output has some specified size/scale factor (1400x900 at 1.5x say) and you
move a 1400x900 surface from that monitor (fully or partially) to
another with a different scale (1400x900 at 1x) you want the window to be
the same size, so the scaling factor shouldn't affect surface sizes.

>                 And what would it then report for physical
>                 width/height, subpixel, make,
>                 model, etc? Seems pretty weird.
> Even if two wl_outputs would be presented, they would have the same
> resolution and scaling factor so priorities still won't matter.

You mean the compositor could "lie" about the scaling factor on one of
the outputs? I guess that is one possibility.

>                 I don't quite understand this. Any factor lower than
>                 the "desired"
>                 factor has to be scaled up, no?
> I expect a compositor to render deviations of the desired scaling
> factor without scaling windows. The range when this is allowed is
> reported to clients so they can try to render at a size which will
> avoid scaling.

I don't think this is really a good idea, as per the above.

>                 Lets take a concrete example. The macbook pro 15" has
>                 a 2880 x 1800
>                 native panel. This is "normally" driven as 1440 x 900
>                 with a scale
>                 factor of 2. On OSX you can also select a 1920x1200
>                 resolution, which is
>                 nominally a scale factor of 1.5. However, on OSX what
>                 they do is that
>                 apps render to a framebuffer at twice the resolution
>                 (3840x2400) and its
>                 then scaled it down to 2880x1800 to make it look
>                 reasonable.
> Rendering at 3840x2400 then scaling down to 2880x1800 is bad for
> performance and makes the result unsharp. It is much preferable that
> clients render into 2880x1800 directly with a 1.5 scaling factor (for
> clients that are capable of doing that).

Well, which is best should be up to the app, but i guess we want to
allow a fractional scaling factor to allow apps to scale by 1.5
themselves if they can.


> We can't really downscale with integer multipliers, just upscale. If
> we downscale, rendering at a (much) higher resolution doesn't really
> help much. We want to avoid upscaling though.

Upscaling is important for backwards compat with apps not supporting
scaling. For instance, we likely need it for old X clients. But yeah,
generally we want to avoid that.

>         I don't know if the upper/lower limits is the solution, but
>         this is certainly an issue.  In a case like that, I would say
>         that the application simply works in the coordinates of the
>         "prefered" output.  This includes input events etc.  This may
>         mean that the size of the window in points isn't an integer.
>         If the toolkit doesn't want to deal with that, they can come
>         up with a solution (maybe just require a multiple of 2 for the
>         size in this case).
>         
> The size of a window should always be in pixels at the protocol level.

What do you mean by window and pixel here. There are multiple pixels and
sizes here:

compositor pixels: 
	The 'compositor coordinate system' is an global space where the
	wl_outputs are laid out.
framebuffer pixels: 
	These correspond to the native LCD panel pixel. 
buffer pixels: 
	These are the individual pixels the clients rendered
surface pixels:  
	These are "pixels" in what the protocol calls "surface local
	coordinates". 

Note that all these exists already, even without scaling due to the
buffer transforms. And they need to be, a window that is rendered
rotated because its mainly on an output that is rotated should still get
its input in the "surface pixel" coordinate system, not the rotated one.

Adding scaling doesn't really add anything here, it just adds a scaling
factor between the compositor pixels and the framebuffer pixels and
between the surface pixels and the buffer pixels. So, a surface is
200x100 even if the buffer is 400x200 with scale 2, just like a surface
is 200x100, even if the buffer is 100x200 with transform 90 degrees.

>         Second, we are going to have to deal with fractional scaling
>         even if we restrict to integers.  Consider the following
>         example.  Say I have two monitors: A and B which are at 200
>         DPI, and 300 DPI respectively.  An application has a number of
>         choices for resolution:
>         
>          - It could render at 200 DPI and then scale by 3/2 for B.
>         
>          - It could render at 300 DPI and scale by 3/2 for A.
>         
>          - It could render at 100 DPI and scale by 2 for A and 3 for B
>         and look bad on both
>         
>          - It could render at 400 DPI and scale by 3/4 for B and 1/2
>         for A
>         
>         
>         and I'm sure you could come up with more.  However, the point
>         is that unless we are going to make the extremely restrictive
>         assumption that monitors come in powers of two, we cannot get
>         around fractional scaling.

True, so I guess allowing fractional scaling in the protocol doesn't
really increase the demand on the compositor. So, lets do that.