<div dir="ltr">On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson <span dir="ltr"><<a href="mailto:alexl@redhat.com" target="_blank">alexl@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote:<br>
<br>
> > Clients can easily scale larger features like icons, padding<br>
> and fonts<br>
> > and round them to pixel sizes and draw sharp output even<br>
> with a<br>
> > fractional scaling factor. This allows users to pick a size<br>
> suitable<br>
> > for them. The difference between a 1 and 2 scaling factor is<br>
> too huge.<br>
><br>
><br>
> Some things can be easily scaled. Like text and photorealistic<br>
> images.<br>
> Other things can't necessarily be scaled and still look nice.<br>
> Like line<br>
> art or solid line borders (like e.g. the boxes around a<br>
> button). Sure,<br>
> you can round everything to "nearest int", but that will cause<br>
> unevenness in the rounding (buttons sometimes get a 1 pixel<br>
> border,<br>
> sometimes 2 depending on the fractional part of the button<br>
> coords, etc).<br>
> So, I don't think this is every useful in practice.<br>
> Even if things aren't perfectly even, it will still be much better<br>
> than the alternative which is round up to the next scaling factor and<br>
> let the compositor scale the surface down to a suitable size again.<br>
> This is what you have to do on Mac OS X to get a reasonable workspace<br>
> on higher DPI displays. Windows gets 4 times bigger from scaling<br>
> factor 1 to 2. That isn't near enough granular.<br>
<br>
</div></div>I don't think this will work in practice. I know for sure that e.g. Gtk<br>
is not set up to do any reasonable non-integer scaling. It will just<br>
scale up all drawing by a fractional factor without any rounding<br>
anywhere, causing everything to become fuzzy. We will eventually have<br>
alternative icons for higher resolutions, but these will be at 2x scale,<br>
not at generic fractional factor (that is not really doable without<br>
using pure-vector icons with some complex hinting method). Although, I<br>
guess that in the case of text the scaling will be ok, so for some<br>
usecases it might be OK.<br></blockquote><div>It will work very well for things designed to be scalable, browsers are an example. GTK could just fall back to integer scaling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, it's my opinion that supporting fractional scaling is an unnecessary<br>
burden on compositors for something that is not very useful in practice.<br>
Thats just my opinion though, and the proposal as such can handle<br>
fractional scaling fine by just changing the scale factors to fixed<br>
type.<br></blockquote><div>It is of no burden on compositors at all, only for clients which choose to implement it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> In mirrored/clone mode only a single wl_output would be presented to<br>
> clients with a single scale factor, so priorities won't matter in that<br>
> case.<br>
<br>
</div>That is not necessarily so. We might very well want to know that there<br>
are two displays, with say different RGB subpixel order, etc.<br></blockquote><div>The compositor could unify this information into a single wl_output.</div><div><br></div><div>I suggest we send 3 scaling factors to clients. A lower bound where factors lower will be scaled up. The desired scaling factor. A upper bound where factors above will be scaled down. Clients should find the scaling factor in lower bound to upper bound they are able to render at which is closes to the desired factor. Failing that they should find the first factor they are able to render at above the upper bound. When displayed on multiple monitors it could try to remain sharp on as many monitors as possible.</div>
<br></div>