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

[Alexander Larsson]

On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 11:16:07 +0200
> Alexander Larsson <alexl at redhat.com> wrote:
> 
> > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> > 
> > > Also, we need to figure out how this interacts with the proposed
> > > scaling extension.  Information can be found here:
> > > http://lists.freedesktop.org/archives/wayland-devel/2013-April/008927.html
> > 
> > I don't think it needs much extension. It works as is, although the docs
> > refering to wl_surface.set_buffer_transform also needs to mention the
> > scaling factor.
> > 
> > Of course, there is also the question of if we could use the
> > wl_surface_scaler interface to do the HiDPI scaling. And, while this
> > would be technically possible it seems the wrong approach to me. The
> > surface scaler API is much more demanding of the compositor with
> > non-integer scaling factors, cropping and aspect ratio changing. I don't
> > think we want to force compositors to always support all of that in
> > order to work on HiDPI displays where a much simpler subset is needed.
> > Also, its a much more complex API to use for something so basic that
> > every window will use it.
> > 
> > Basically, wl_surface_scaler is for scaling of subsurfaces with video,
> > and I don't think we should mix the two up.
> 
> I agree with your reasoning here.
> 
> I haven't read this whole thread in detail, because it seems to contain
> so much "marketing speak" and complicated explanations of things that
> should be straightforward. So, am I getting the following right?
> 
> You basically want a default scaling factor for all surfaces, per
> output. And, you want a way for clients to opt-out from that default
> scaling.

No, that doesn't seem quite right, although maybe I misunderstood it.
Lemme try to define it similarly.

Each output has a scaling factor set, and all surfaces on that output is
scaled by it. However, clients can supply pre-scaled buffers, which
co-incidentally allows sub-pixel accuracy in the "scaling" by just
rendering at a higher resolution.

Basically, compare it to the current wl_surface.set_buffer_transform().
Its essentially that, but the transform extended with scale-by-integer
in addition to the rotations.

> Is it really that simple? I'm asking because I didn't see it put that
> clearly anywhere, but maybe it got lost in between all the 3DTV
> discussion and coordinate transforms.

Sure, its pretty simple in the end.