[PATCH 00/15] weston scaling support

[John Kåre Alsaker]

On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 28 May 2013 19:27:35 +0200
> John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
>
> > My proposal is simply to let the compositor tell the client how much
> larger
> > it wants the client to render content. The client can then tell the
> > compositor how much larger it made content in the window. Armed with this
> > information the compositor can size the window accordingly.
>
> How would this look in protocol? Just roughly, what requests and events
> would be involved. Especially, how does the compositor know to suggest
> a size?
>
We add a new event to wl_output to tell clients how much larger they should
create their windows for optimal display on that output. Clients should
then create larger windows and indicate so by a new request on wl_surface
where they state how much they enlarged the window. This differs from
Alexander's implementation in that the window itself is larger rather than
the buffer.


>
> > Note that this implies no further change in the protocol or concepts.
> > Surface coordinates are still of the same size as buffer coordinates.
>
> Alright.
>
> > This has a number of benefits over the current implementation:
> > + Rational scaling factors has no issues (the most important benefit).
>
> I think they may have issues. A surface pel may not cover an integer
> amount of pixels in both buffer and output. Or how do you arrange that?
>
A surface pel would correspond exactly with a pixel in the buffer, although
it might be flipped or rotated. There's no guaranteed correspondence with
an output pixel in either proposal.

>
> For crisp pel-sized graphics (pixel-sized in apps that do not
> understand the output scale), a pel should be an integer amount of
> pixels in both output and buffer.
>
How the compositor resizes surfaces is not defined by either proposal. It
may not do it at all or it may only upsize with a integer multiple.


> > + Output sizes do not have to be a multiple of the scaling factor.
>
Clients won't be able to fill the output exactly when the output size is
not a multiple of the scale factor. With a scaling factor of 3, 2560x1600
would be 853.3... x 533.3.... This can't be represented in the protocol so
it will need to be cropped or padding added.

> + Clients can specify their size in pixels exactly.
>
Client doesn't have to round to the nearest multiple of the scaling factor.


> > + Clients get input in exact pixels (no rounding errors).
>
With a scaling factor of 3, you're suddenly unable to address individual
pixels.


> > + Clients doesn't have to transform input events in order to match the
> > sizes used by buffers.
>
Toolkits may store geometry in actual pixels and need events to match
pixels and not some virtual unit. That's how I'd design one.


>
> I don't really get the above.
>
> > + Conceptually simple to implement. Compositors doesn't have to deal with
> > scaling for subsurfaces and they are probably already able to resize
> whole
> > windows.
>
> Why would sub-surfaces have any effect here?
>
I have absolutely no idea how subsurfaces trees with different scaling
factors on surfaces would work in Alexander's proposal. I simply don't
allow specifying it on anything other than top level surfaces, which it
uses for the whole surface tree.

>
> > + Can support clients with integer scaling factors, although these raises
> > the same edge cases as the current implementation (they may not be able
> to
> > fit the screen exactly).
> >
> > There are however some downsides:
> > - Clients may need to transform input events in order to match the
> > coordinates used by applications.
>
> So this is a minus here, but the same wrt. buffers was a plus. And it's
> the application that first deals with input events, and then decides
> what to draw. I don't think input goes directly to drawing machinery.
>
It will depends on how the toolkits interprets events. If you want to hack
a toolkit by multiplying all buffer sizes by an integer (which Alexander is
plotting with GTK) yet keep everything else the same this proposal will
require transforming the input events too. The comparison with buffers was
because normally toolkits store element sizes as the size in rendered
pixels.


>
> > - Clients changing scaling factors will have older input reported in the
> > old size. This will be quite rare although clients can deal with it if
> > desired.
> > - Requires an implementation <:)
> >
> > I don't expect GTK or other (ancient) toolkits to do fractional scaling
> and
> > reap all the benefits listed here. I don't want anything in the core
> > protocol blocking the ability for clients to scale smoothly up though
> when
> > clients will actually be able to do this.
>
> You listed some features, but I still have no idea what you are
> suggesting.
>
> It also seems the integer output scale proposal and implementation are
> maturing nicely, so now there would need to be obvious reasons for
> changing it. I just don't see it based on this description.
>
> - pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130603/4c599950/attachment-0001.html>