[wayland HiDPI support, posible regression?]

[microcai]

on Monday 16 March 2015 20:39:15，Jasper St. Pierre wrote：
> "dumb" clients also include X11 clients for legacy Xwayland compatibility.
> Of which there a lot of.
> 

xwayland will not have buffer scale support anyway. besides, qt and gtk on X11 
already do well at DPI-independence.

> On Mar 16, 2015 8:35 PM, "microcai" <microcai at fedoraproject.org> wrote:
> > on Monday 16 March 2015 20:28:48，Daniel Stone wrote：
> > 
> > > Hi,
> > > 
> > > On 16 March 2015 at 00:35, Jason Ekstrand <jason at jlekstrand.net> wrote:
> > > > On Tue, Mar 10, 2015 at 12:00 PM, Bill Spitzak <spitzak at gmail.com>
> > 
> > wrote:
> > > >> [blah blah blah]
> > > >> 
> > > >> Events seem to be ok, but my complaint is that a large number of
> > > >> coordinates in the api other than events are in integer logical
> > 
> > pixels,
> > 
> > > >> not in high dpi or in fixed-point. The offsets to attach are the
> > 
> > biggest
> > 
> > > >> culprits. There are also integer clip rectangles in the subsurface
> > > >> and
> > > >> scaling apis. Except for compatibility there is no reason positions
> > > >> in
> > > >> messages cannot be in buffer pixels.
> > > 
> > > 'Except for compatibility', yeah. That's like saying that there's no
> > > reason for me to have a job, except for the need to house and feed
> > > myself. Kind of a showstopper, that.
> > > 
> > > Smart clients do not require buffer scaling. The scaling is there as a
> > > fallback to make clients who are blissfully unaware of the constraints
> > > of high-DPI screens still work: no more, no less. Clients who have the
> > > smarts to deal with resolution/DPI-independence will _already_ be
> > > doing smart layout which avoids the need for buffer scaling.
> > 
> > any client *has to be* smart client anyway. buffer scalling is such
> > pointless.
> > 
> > > Any talk of throwing away buffer scaling (breaking dumb clients) in
> > > order to fit the uses of clients who already today avoid buffer
> > > scaling, is utterly pointless. Any attempt to handwave away the
> > > disadvantages as nonexistent is disingenuous.
> > > 
> > > > Please do not take a thread started by someone who is obviously
> > > > confused and side-track it into a discussion of things that you think
> > > > are design-flaws in the current protocol.  This is not the appropriate
> > > > place for a discussion of wl_surface.attach (x, y) coordinate systems
> > > > and bringing that up only adds to the confusion.
> > > 
> > > Yes, exactly.
> > > 
> > > Yet again, this is something you have repeatedly brought up every time
> > > something even tangentially related is mentioned. You've explained
> > > your concerns over and over, and it's obvious that our opinions differ
> > > and upstream will not change. Doing this makes it infinitely less
> > > likely that your concerns will be taken seriously (cf. the
> > > wl_keyboard_grab bug): the first reaction to seeing your name come up
> > > in a thread is 'oh god, not again'. Which is a shame, as you do have
> > > valuable input to offer, but it's drowned out by the amount that you
> > > bang on about your pet peeves, with a total inability to accept that
> > > someone with a differing opinion may just have a different opinion,
> > > not be objectively wrong. Everyone loses: you don't get taken
> > > seriously, we get frustrated, discussions get derailed, and people who
> > > don't know better mistake your loud pronouncements for upstream's
> > > actual position (or, when those differ from measurable reality rather
> > > than opinion, a useful fact).
> > > 
> > > Be the signal, not the noise.
> > > 
> > > Cheers,
> > > Daniel