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

[Pekka Paalanen]

On Mon, 13 May 2013 13:14:29 +0200
Alexander Larsson <alexl at redhat.com> wrote:

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

Yup, that is exactly it, you just added some details on how to
implement the idea with protocol.

Henceforth, if a compositor implements this feature, unmodified old
clients will show up scaled automatically and just work. Clients that
know this feature may choose to take advantage of the available higher
resolution. Sounds cool.

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

I'll wait for the protocol interface versioning issues to be solved,
and assume you will then send a revised version. It will be easier for
me to get on board then, unless I'm again caught in a busy project.


Cheers,
pq