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? > 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. > 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. 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
