<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Automatically scale windows?" href="https://bugs.freedesktop.org/show_bug.cgi?id=93315#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Automatically scale windows?" href="https://bugs.freedesktop.org/show_bug.cgi?id=93315">bug 93315</a> from <a class="email" href="mailto:daniel@fooishbar.org" title="Daniel Stone <daniel@fooishbar.org>"> Daniel Stone</a> <pre>(In reply to Alexander Larsson from <a href="show_bug.cgi?id=93315#c12">comment #12</a>) > I don't think that is really a problem though. > > not dynamic: We could just always allocate a scale 2 screen. > > can't blit across screens: When would you need that. Apps would generally > just connect to either one, and ignore the other. The compositor can do > blitting on the wayland side. > > windows can't share screens or move to other screen: Well, either the app > has no knowledge of hidpi, we then always want it to be on the screen that > has scale=1 (i.e. is scaled up if the real output is scale=2). Apps that are > hidpi aware are passed the unmodified screen (and some env var is set about > the scale), and then they can render in full resolution. Then the compositor > can scale these down to scale=1 outputs in the mixed-scale case. Hm, right; I think that could well work, but would require a fair bit of surgery. Especially on the XWayland side, where we have to perform the mapping back into a fixed/linear co-ordinate space. But yeah, it could well just work ...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>