<div dir="ltr">Mon, May 13, 2013 at 1:26 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 class="im">On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:<br>
<br>
> The scaling factor should not have any affect of any coordinate system<br>
> or anything else in the protocol. It should only affect the size in<br>
> pixels of the surfaces of the clients. Clients should do any<br>
> transformations of coordinates they want themselves.<br>
<br>
</div>I'm not sure if we agree or not here. But, lemme have an example. If you<br>
have a setup with two monitors using mirrored mode, one with scale == 2.<br>
Then I want both monitors to show the same thing, one with more detail.<br>
If I then put the mouse cursor over the bottom right corner of the<br>
surface i want to get one mouse event, and the coordinates of it should<br>
be the size of the window in the unscaled coordinates, i.e. the<br>
width/height of the window in the lower resolution.<br></blockquote><div>The client should get the width and height of the surface in pixels. If the compositor doesn't display pixels in a 1:1 ratio on the monitor, it should translate events into pixels in surface coordinates before sending them to a client. The scaling factor should have no effect on anything (from a protocol perspective) other than which pixel sizes the client picks.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is this what you meant?<br>
<div class="im"><br>
> Clients can easily scale larger features like icons, padding and fonts<br>
> and round them to pixel sizes and draw sharp output even with a<br>
> fractional scaling factor. This allows users to pick a size suitable<br>
> for them. The difference between a 1 and 2 scaling factor is too huge.<br>
<br>
</div>Some things can be easily scaled. Like text and photorealistic images.<br>
Other things can't necessarily be scaled and still look nice. Like line<br>
art or solid line borders (like e.g. the boxes around a 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 border,<br>
sometimes 2 depending on the fractional part of the button coords, etc).<br>
So, I don't think this is every useful in practice.<br></blockquote><div>Even if things aren't perfectly even, it will still be much better than the alternative which is round up to the next scaling factor and let the compositor scale the surface down to a suitable size again. This is what you have to do on Mac OS X to get a reasonable workspace on higher DPI displays. Windows gets 4 times bigger from scaling factor 1 to 2. That isn't near enough granular.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> I think the case when a window is displayed on multiple monitors is<br>
> pretty rare or short in duration (the dragging across monitor case<br>
> when not using a workspace per monitor). I suppose we could leave this<br>
> up to the compositor.<br>
<br>
</div>Totally, i don't mean that the priority is useful for that case.<br>
Normally clients should just pick the scale based on which output the<br>
surface has the "most" pixels in. However, the one case where that<br>
breaks is mirrored/clone mode, where two monitors show the same thing.<br>
This is where the priority can be useful.<br></blockquote><div>In mirrored/clone mode only a single wl_output would be presented to clients with a single scale factor, so priorities won't matter in that case. </div><br>
</div>