<div dir="ltr">On Tue, May 14, 2013 at 5:49 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 tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote:<br>
<br>
<br>
>         Obviously they are defined as such right now, since there is<br>
>         no scaling.<br>
>          But, the patch I proposed changes this,<br>
><br>
>         because otherwise we can't<br>
>         cleanly handle backwards compatibility (and also it makes<br>
>         sense).<br>
> Backwards compatibility with what?<br>
<br>
</div>With existing wayland clients that don't do sbupixel accuracy. Did you<br>
ever try a current wayland app on a 240 dpi display?<br></blockquote><div>I thought you were referring to something else since there's still won't be any scaling from buffer to surface coordinates in the legacy client case.</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>
> How would you handle subsurfaces with different scaling factors? What<br>
> coordinates would the subsurface's position be in?<br>
<br>
</div>All positions are in the global compositor coordinate space. The one<br>
that e.g. different outputs are positioned in, etc.<br></blockquote><div>That won't work. Currently a subsurface's position is relative to the parent surface in the parent's surface coordinates.</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>
>         We can't have the configure event say 2000x2000, because then<br>
>         old<br>
>         clients will not be auto-upscaled as we want.<br>
> In this case our proposals differs. The compositor knows it's not<br>
> resizing the window so it simply passes 2000x2000 along to the<br>
> configure arguments.<br>
<br>
</div>How can the compositor know its not resizing the window? Only the app<br>
knows if it can render at a different scaling factor, as it is the app<br>
that allocates and draws to the buffer.<br></blockquote><div>The compositor knows if it's drawing pixels at a 1:1 rate or if it's doing resizing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Anyway, its pretty obvious that you're talking about a different design.<br>
I'm growing tired of this discussion, I will just shut up and implement<br>
my design in weston. If you want to implement a competing desing, feel<br>
free.<br>
<br>
<br>
</blockquote><br></div>