<div dir="ltr">On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><div class="h5">On Tue, 28 May 2013 15:10:53 +0200<br>
John Kåre Alsaker <<a href="mailto:john.kare.alsaker@gmail.com">john.kare.alsaker@gmail.com</a>> wrote:<br>
<br>
> On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>>wrote:<br>
><br>
> > I read through the latest wayland protocol patches and the discussion<br>
> > around them and didn't seen anything I didn't like.  I think the<br>
> > approach here is good and agree with the consensus.  This patch series<br>
> > looks great too and I like the improvements to the pixman renderer and<br>
> > the compositor-x11.c optimization.<br>
> ><br>
> Where did the consensus come from?<br>
><br>
> I think the lack of fractional scale factors will result in further<br>
> extensions to support that in the future. I really also dislike how this<br>
> implementation won't allow clients to draw with pixel precision on scaling<br>
> factors above 1.<br>
<br>
</div></div>Quite the contrary, it does allow drawing at least at pel precision, and<br>
it even guarantees that a pel always accurately hits the pixel<br>
boundaries in both the buffer, and all outputs regardless of their<br>
scale factor (provided the compositor does not do additional<br>
transformations of its own).<br></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Introduce rational factors, and it can only be of worse image quality,<br>
combined with a lot of protocol and interpretation difficulties, when<br>
sizes are suddenly not integers.<br></blockquote><div>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.</div>
<div>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?</div><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you really need an output scaling factor like 1.5, then you report it<br>
as either 1 or 2, and do a compensating scaling in the compositor to<br>
achieve 1.5. That is the best compromize I can imagine, since to be<br>
honest, 1.5 does not work for the protocol nor the clients' rendering.<br></blockquote><div>1.5 works just fine for the protocol and clients' rendering.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I thought I explained that before, maybe to someone else, but on this<br>
mailing list anyway.<br>
<br>
<br>
- pq<br>
</blockquote><br></div>