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

[John Kåre Alsaker]

On Tue, May 14, 2013 at 3:19 PM, Alexander Larsson <alexl at redhat.com> wrote:

> On tis, 2013-05-14 at 13:19 +0200, John Kåre Alsaker wrote:
> > On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson
> > <alexl at redhat.com>
> >
> >         I don't think it should really be allowed to not apply the
> >         scaling.
> > Users may want to disable scaling as it's not very good looking. I
> > don't think we should enforce a policy about that.
>
> What do you mean? Scaling is done by the compositor. The user is who
> tells the compositor to use scaling (by setting a scale on the
> wl_outputs), just like he sets the resolution.
>
I might have been unclear. Users may want to disable resizing of buffer
pixels in the compositor. However clients which able to draw at the correct
scaling factor should still do so and appear pixel perfect.


> >         Right now buffer sizes define surface sizes, and that makes
> >         surface
> >          sizes not really well defined.
> > They're defined as the same as buffer sizes (ignoring the trivial
> > transformations). They should still be the same if the scaling factor
> > is not 1.0. Clients should scale both buffers and surfaces. The only
> > thing that should decouple these sizes more are the scaling extension.
>
> Obviously they are defined as such right now, since there is no scaling.
>  But, the patch I proposed changes this,



> because otherwise we can't
> cleanly handle backwards compatibility (and also it makes sense).
>
Backwards compatibility with what?

How would you handle subsurfaces with different scaling factors? What
coordinates would the subsurface's position be in?


> In the canonical example of 2x scaling you have some lcd panel at say
> 2000x2000, and we want naive apps to be automatically upscaled as if it
> was a 1000x1000 monitor. If a window in the naive app is maximized this
> means it must get a configure reply from maximize that says 1000x1000,
> which cause it to attach a buffer of 1000x1000 (with scale factor 1) to
> it. This is how existing wayland clients work.
>
In my proposal the compositor will scale down configure arguments by the
same amount it resizes the window up.


> Now, a non-naive client will get the same maximize reply of 1000x1000,
> but in this case we want it to create a buffer of 2000x2000 (with scale
> 2) since it knows the window is on a high-dpi monitor. So, there is a
> natural separation of the surface size (1000x1000) and the buffer size
> (2000x2000).
>
> We can't have the configure event say 2000x2000, because then old
> clients will not be auto-upscaled as we want.
>
In this case our proposals differs. The compositor knows it's not resizing
the window so it simply passes 2000x2000 along to the configure arguments.

It's also worth considering the edge cases when pixels doesn't scale down
so easily. Say we have a workspace of 2000x1901 and we have a scaling
factor of 2 and we want to maximize the client.
With a scale factor unaware legacy client we'd have to send 1000x950.5
which would have to be rounded to 1000x951. We could compensate by cropping
or stretching to fill the workspace.
With a client using a scaling factor of 2 I'd send 2000x1901 which the
client might be able to fill exactly or it might just pretend it's
2000x1902 and crop the result. In your proposal this would still have to be
rounded to 1000x951 and clients able to fill 2000x1901 exactly would render
at 2000x1902 instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130514/8c8ee288/attachment.html>