On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson <al...@redhat.com> wrote:
> On tis, 2013-05-14 at 17:00 +0200, John Kåre Alsaker wrote: > > > > Obviously they are defined as such right now, since there is > > no scaling. > > But, the patch I proposed changes this, > > > > because otherwise we can't > > cleanly handle backwards compatibility (and also it makes > > sense). > > Backwards compatibility with what? > > With existing wayland clients that don't do sbupixel accuracy. Did you > ever try a current wayland app on a 240 dpi display? > 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. > > How would you handle subsurfaces with different scaling factors? What > > coordinates would the subsurface's position be in? > > All positions are in the global compositor coordinate space. The one > that e.g. different outputs are positioned in, etc. > That won't work. Currently a subsurface's position is relative to the parent surface in the parent's surface coordinates. > > We can't have the configure event say 2000x2000, because then > > old > > clients will not be auto-upscaled as we want. > > In this case our proposals differs. The compositor knows it's not > > resizing the window so it simply passes 2000x2000 along to the > > configure arguments. > > How can the compositor know its not resizing the window? Only the app > knows if it can render at a different scaling factor, as it is the app > that allocates and draws to the buffer. > The compositor knows if it's drawing pixels at a 1:1 rate or if it's doing resizing. > Anyway, its pretty obvious that you're talking about a different design. > I'm growing tired of this discussion, I will just shut up and implement > my design in weston. If you want to implement a competing desing, feel > free. > > >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
