[PATCH 0/2] Support for high DPI outputs via scaling

[John Kåre Alsaker]

On Tue, May 14, 2013 at 5:49 PM, Alexander Larsson <alexl at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130514/a48d1f51/attachment.html>