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

[John Kåre Alsaker]

On Tue, May 14, 2013 at 11:25 AM, Alexander Larsson <alexl at redhat.com>wrote:

> 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.
>
Users may want to disable scaling as it's not very good looking. I don't
think we should enforce a policy about that.


> 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.


> 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.

You can't scale the input from configure. You are required to create a
surface of that size in surface pixels in order for it to match the screen.
Clients should still scale content based on the scaling factor even if it
isn't in control of the surface size.


> 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.
>
It is much much more important that the input remains sharp than exactly
the same size. When the client is moved to another output it can resize
itself to better suit the scaling factor of it, if it's able to.

>> 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".
>
Most things in the protocol uses surface pixels which is what I usually
mean by pixels.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130514/b7f176bd/attachment.html>