Announcement

Collapse
No announcement yet.

Better KWin Wayland HiDPI Support Still Baking

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • darkbasic
    replied
    Originally posted by darkbasic View Post
    "Despite Qt having quite good fractional scaling support, the wayland protocol limits itself to integers. This is in the very core protocol and somewhat hard to avoid. However, there's technically nothing stopping kwin from scaling to a different size than it tells the client to scale at..."

    Why not fixing the Wayland protocol instead? Why did they choose to not allow fractional scaling?
    "How will you handle fractional scaling on Wayland which only allows integer scaling?"

    "At first, by upscaling in the client, and downscaling in the compositor. But there’s also some idea of doing a Wayland protocol extension."

    Source: https://blogs.gnome.org/mclasen/2017...ing-goes-east/

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by Griffin View Post
    https://blogs.gnome.org/mclasen/2017...ing-goes-east/

    Lol, and now Gnome takes it to the next level.
    So GNOME is again playing catch-up.

    Leave a comment:


  • GreatEmerald
    replied
    Huh, fractional scaling not being part of Wayland is really odd. And quite sad for my tablet, which is 144 DPI... that's exactly 1.5x. 1x is way too small and 2x is way too large.

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by Griffin View Post
    Wise choice, and no suprise. With a code base like KDE it is expected that your fix is another man's bug. There is no shame to being second or third. Meanwhile the reference desktop will move further ahead completely ignoring inaccuracies from gotwig
    At this point I have to ask myself if I should laugh about you or feel sorry for you. You life must be really miserable if you have to define yourself over the work someone else has done instead of your own achievements.

    Leave a comment:


  • polarathene
    replied
    Originally posted by CrystalGamma View Post
    I have yet to understand why Wayland uses scaling factors based on 96DPI instead of putting DPI right there in the protocol. (Maybe the compositor could have transmitted two numbers per axis: the number of pixels in a meter and the (pixel) size of the smallest desired interactive element, because you want bigger buttons on a touchscreen than a system with only a mouse …)
    I know that in the browser world CSS is based on 96DPI or rather 96 pixels per inch? IIRC, a square of 96px width/height would be 1 inch width/height even on 120dpi or 300dpi display/resolution/print. You could apply a zoom/scaling factor though(I think this is desktop browser +/- zoom buttons), depending on style rules that may get ugly vs an actual scale/zoom that you might do in your mobile browser with your hand(scaling the viewport not values).

    No idea what Wayland is doing, but maybe it's more like a reference value that would translate to actual DPI of the device(see PhantomJS for printing PDFs of webpages, Linux/Windows/macOS output different sizes due to their native OS DPI(different from display DPI), not sure if that's been fixed yet, I know a fix ended up flipping the problem). Scaling by integer values might be a quality thing if it's scaling texture pixels(assuming rendered contents is on the GPU managed in textures), floating point values in that approach tend to have issues like quality. If instead the values could be scaled prior to being rendered into pixels/textures, floating point might work better then?(scaled values that are not integers may get rounded up/down to fit a full pixel however where rendered elements might look slightly offset) This is just going off my experience working with various technologies in the past(Starling framework for Adobe AIR using GPU on mobile devices and how scaling worked there, and CSS for websites printing to PDFs).

    With web you'd be able to have individual elements be at a larger scale or different style based on pixels/DPI and width/height of the element/container available. On Starling, you could do similar but you could also note the scaling factor to decide if elements like buttons should be larger and treated differently.
    Last edited by polarathene; 18 May 2017, 10:08 PM.

    Leave a comment:


  • andrebrait
    replied
    Regarding GNOME, I have found that setting the font scaling to 1.5 using the GNOME Tweak Tools provides a very satisfying result (for me, at least) for the time being. It scales some of the UI as well.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Griffin View Post
    Haha. KDE actually contributing to Wayland?
    Please note, the same applies to GNOME here (as none has yet sent in a patch for this). Where is the businness-grade QA when you need it most?

    Leave a comment:


  • CrystalGamma
    replied
    I have yet to understand why Wayland uses scaling factors based on 96DPI instead of putting DPI right there in the protocol. (Maybe the compositor could have transmitted two numbers per axis: the number of pixels in a meter and the (pixel) size of the smallest desired interactive element, because you want bigger buttons on a touchscreen than a system with only a mouse …)

    Leave a comment:


  • darkbasic
    replied
    "Despite Qt having quite good fractional scaling support, the wayland protocol limits itself to integers. This is in the very core protocol and somewhat hard to avoid. However, there's technically nothing stopping kwin from scaling to a different size than it tells the client to scale at..."

    Why not fixing the Wayland protocol instead? Why did they choose to not allow fractional scaling?

    Leave a comment:


  • rtfazeberdee
    replied
    Originally posted by gotwig View Post
    And GNOME devs dont give a f*ck The HiDPI support in GNOME is so bad... i have a 14" FullHD screen and I can't use it, because it doesnt support floating values like 1,2 scaling, but only full integer scaling like 2x time scaling or 3x scaling. Super useless. For years.

    But hey , its gnome, I guess they focus on recipe apps instead.
    I'm sure Griffin-troll will have something to say about that...

    Leave a comment:

Working...
X