[PATCH 00/15] weston scaling support

[Pekka Paalanen]

On Tue, 28 May 2013 17:03:29 +0200
John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:

> On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > On Tue, 28 May 2013 15:10:53 +0200
> > John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
> >
> > > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg <hoegsberg at gmail.com
> > >wrote:
> > >
> > > > I read through the latest wayland protocol patches and the discussion
> > > > around them and didn't seen anything I didn't like.  I think the
> > > > approach here is good and agree with the consensus.  This patch series
> > > > looks great too and I like the improvements to the pixman renderer and
> > > > the compositor-x11.c optimization.
> > > >
> > > Where did the consensus come from?
> > >
> > > I think the lack of fractional scale factors will result in further
> > > extensions to support that in the future. I really also dislike how this
> > > implementation won't allow clients to draw with pixel precision on
> > scaling
> > > factors above 1.
> >
> > Quite the contrary, it does allow drawing at least at pel precision, and
> > it even guarantees that a pel always accurately hits the pixel
> > boundaries in both the buffer, and all outputs regardless of their
> > scale factor (provided the compositor does not do additional
> > transformations of its own).
> >
> The only problem is that pel precision is not pixel precision. Furthermore
> output sizes are not aligned with pel unit sizes, they are in pixels.

Output size does not matter, and wl_output reports modes in true
pixels. Any issues with fullscreening are quite easily defined,
including allowing direct scanout.

At least with integer factors, a pel will always occupy an integer
number of pixels in both dimensions, regardless of output_scale or
buffer_scale. You can still choose the output_scale as your
buffer_scale, and do pixel precision rendering on that output. If you
consider outputs with different scales, you are screwed in any case.

> > Introduce rational factors, and it can only be of worse image quality,
> > combined with a lot of protocol and interpretation difficulties, when
> > sizes are suddenly not integers.
> >
> Which protocol and interpretation difficulties are you referring to? I've
> not found any in my proposal, buffer and surface sizes are still in
> integers there.

All the ones raised along the previous thread. Which email was the
proposal you refer to?

> I do wonder what happens if you attach a buffer of size 101x101 in the
> current implementation with a scale factor of two. Is the compositor
> expected to use 50.5x50.5 as the surface size?

Using odd surface dimensions with a buffer_scale=2 is a client error.
It is nothing the compositor needs to support correctly, even if one
could define what correct would be.

If you allow rational scaling factors, we either need a lot more
complex rules about sizes, or then the compositor must always deal with
fractional sizes, and we need to define all the behaviour in every step
that may round. That is nasty.

> While rendering at rational factor can't be of better quality, it can
> however be done at a much higher quality than downscaling, faster and with
> less memory usage.

Perhaps, but that benefit diminishes compared to the cons.

> > If you really need an output scaling factor like 1.5, then you report it
> > as either 1 or 2, and do a compensating scaling in the compositor to
> > achieve 1.5. That is the best compromize I can imagine, since to be
> > honest, 1.5 does not work for the protocol nor the clients' rendering.
> >
> 1.5 works just fine for the protocol and clients' rendering.

We cannot clip regions to fractional sizes, nor express them in the
protocol. We would need lots of rounding rules in the protocol, which
just makes everything more complex.

Ever tried to render a crisp line, like a button border, as 1.5 pixels
wide?

Also:
On Wed, 22 May 2013 10:12:00 +0200
Alexander Larsson <alexl at redhat.com> wrote:

> On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote:
> > On Tue, 21 May 2013 08:35:53 -0700
> > Bill Spitzak <spitzak at gmail.com> wrote:
> 
> > > This proposal does not actually restrict widget positions or line sizes, 
> > > since they are drawn by the client at buffer resolution. Although 
> > 
> > No, but I expect the toolkits may.
> 
> Gtk very much will do this at least.

- pq