[wayland HiDPI support, posible regression?]

[Jasper St. Pierre]

Hi-DPI displays and resolution independence are two completely different
problems. You don't get resolution independence by scaling, it needs
separate design and a responsive layout. The scale is simply for displays
where the pixel density is double or triple other displays.

On Thu, Mar 12, 2015 at 9:08 AM, microcai <microcai at fedoraproject.org>
wrote:

> on Monday 09 March 2015 08:59:35，Jasper St. Pierre wrote：
> > You misunderstood what pq said.
> >
> > You work in "logical pixels". On a hi-DPI display, with twice the pixel
> > density, each "logical pixel" is backed by 4 device pixels. Your actual
> > backing surface containing the pixels is in "device pixels".
>
> assume we design for 72DPI screen, then , yes, we are working on logical
> pixels even when we use  12point font, because 1point=1pixel on 72DPI
> screen.
>
> then the point became the "logical pixel".
>
> Just look at android, we have 4" screen range from 320p to 1080p, they
> don't
> really do 2x scale. but people still expect the *same* UI size.
>
> if you force only 2x scale, the you are lost in the real world. you simply
> can
> not run on 1080p screen when you have your app design for 720p screen, even
> then they share the same physical size, and people expect the same UI
> element
> sizes on the same physical sized screen.
>
> >
> > So, if you have an window that is 800x600 logical pixels, when you drag
> it
> > to a low-DPI display, your backing buffer is 800x600 device pixels. When
> > you drag it to a hi-DPI display, your backing buffer is 1600x1200 device
> > pixels.
> >
> > When you submit your buffer, you tell the compositor what the ratio of
> > device pixels to logical pixels is, in the perhaps misnamed
> > "set_buffer_scale" request. So, for the low-DPI buffer, you submit "1",
> > since 800x600 / 800x600 = 1. When you submit your hi-DPI buffer, you
> submit
> > "2", since 1600x1200 / 800x600 = 2.
> >
> > If you submit "1" and you are on a low-DPI display, it all matches and
> > things are fine. If you submit "1" and you are on a hi-DPI display, the
> > compositor scales up your buffer to match. If you submit "2" and you are
> on
> > a hi-DPI display, it all matches up and things are fine. If you submit
> "2"
> > and you are on a low-DPI display, the compositor scales down your buffer
> to
> > match.
> >
> > On Mon, Mar 9, 2015 at 6:19 AM, microcai <microcai at fedoraproject.org>
> wrote:
> > > 在 2015年3月9日 Monday 10:39:20，您写道：
> > >
> > > > Hi,
> > > >
> > > > On Monday, March 9, 2015, microcai <microcai at fedoraproject.org>
> wrote:
> > > > > so we are forcing two code pathes in APP? or just support
> non-integer
> > > > > scale?
> > > >
> > > > Scaling is a specific fallback for legacy/non-DPI-aware clients, to
> get
> > > > them to show anything at all. Other clients will render at the
> > >
> > > appropriate
> > >
> > > > resolution already.
> > >
> > > That's not the story I was told. pg says scale is the *only way* to
> > > support
> > > HiDPI.
> > >
> > > > Any plan that relies on integer scaling means you're wasting pixels
> on
> > >
> > > your
> > >
> > > > lovely dense display. Any plan that relies on non-integer scaling
> makes
> > > > your text blurry to the point of unreadable - again, a waste of
> pixels
> > > > on
> > > > such lovely displays. Just render at the correct scale to begin with.
> > > >
> > > > Cheers,
> > > > Daniel
> > >
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150312/4130c41c/attachment.html>