On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote: > I think we should allow fractional scale factors. Clients which only > support integer scale factors should round the scale factor they get > to a whole number.
I don't see how this is useful? The scaling has two main benefits: 1) It defines a common global coordinate system in which to specify global things like window sizes, mouse speed, pointer size, relative monitor positions, etc. For these it doesn't necessarily matter that the DPI of these match exactly, only that they are "of the same magnitude". I personally have a desktop setup with two different monitors of different DPI, which works fine. However, I also have a chromebook pixel with 239 dpi, and using the same settings for these things *definately* is a problem on that. 2) It allows reusing all existing code and assets that specify things in pixels. The fact that the theme specifying a one-pixel border on buttons end up with a 3% wider line on some displays is not really a problem. However, on the pixel it is again a real problem. Surface scaling lets us fix this without modifying and duplicating all widget code, themes, svgs, etc. A fractional scale factor is always going to cause visually poor experience due to nr 2. I.e. themes will use an integer multiple wide lines and padding in order to look good on current resolution screens, which will always end up looking blurry if you then scale by a fraction. In fact, if the scaling factor is e.g. 1.5, there is no way for a theme to get crisp button borders. It could specify a line of width 0.66666667 and hope it gets rounded to exactly 1 on the output, but if some padding above it made it accidentally end up on an uneven row it would become blurred between two rows on the screen. It also causes issues because buffers are by necessity of integer sizes, and an integer buffer size times a fractional scale will cause the surface to have a fractional size in the global coordinate space. How would you handle this if the window overlaps an output with a different scaling factor? You'll end up with either a cut off window not showing the last row or a blurred partial pixel rendered with AA. How would you maximize a window when the interger output size results in a fractional buffer size for the window? > I don't think we need a scale priority on wl_outputs, clients should > pick the highest scale factor of the outputs it's on. I don't agree. This is a policy decision, as it will always result in the best looking output on the highest dpi monitor. The lower one would get a downscale of the hires rendering, which will look worse than e.g. a properly hinted text rendered for the lower resolution, and I can easily imagine situations where you want the output to look sharpest on the lower resolution monitor, like when you're using a projector. What to pick in this case should be up to the user and/or compositor/desktop-environment, so we should allow the compositor to tell clients what to do in this case. This is what e.g. OSX does (i.e. you get a popup that asks if you want best looking result on the monitor or on the laptop display). _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
