Announcement

Collapse
No announcement yet.

KDE Plasma 5.21 Now In Beta With Much Improved Wayland Support

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

  • #41
    Originally posted by Ladis View Post



    Windows handles this perfectly - supports both HighDPI apps (the older ones, like X11) and MultiDPI apps (the newer ones, like Wayland). On Linux, you have to choose between those. Means, on X11 you can't handle monitors with different DPIs (in older DEs there was a trick it sent an event the DPI changed and some apps responded to it, some needed restarting), on Wayland even apps which support HighDPI are rendered in LowDPI and stretched (blurry). On Windows, it renders HighDPI apps in the primary monitor's DPI and then stretches as a bitmap on other monitors (in a single-monitor setup you don't know the app is old - it's still crisp). Fun fact: I read somewhere, maybe here on Phoronix, on Fedora/Wayland it uses that hack - it sends the correct DPI and the DPI-changed event like on X11 when you run Chrome/X11 via XWayland (so for users it looks correct, but requires knowing the app will respond to that X11 event).

    EDIT: This is the difference between Windows and Linux. On Windows, they just added few more system events an app can respond to (plus the Compatibility tab in the app's properties to force one way or another). On Linux you have to rewrite all the drawing code in your app (or people making the GUI toolkits have to and you have to update your code to use the new version of the toolkit). This causes much faster adoption among apps on Windows than on Linux (especially maintaining 2 codepaths to keep X11 users supported). I understand the security reasons, but I believe there were ways on X11 to work it around (like those apps to separate X11 apps to own processes yet drawing them together on one desktop; Windows had similar issues - I remember all GDI resources, like brushes, were globally shared among all apps to fit in 4 MB of RAM - the minimum requirement for Win95).
    That's not the difference. The difference is Microsoft owns the toolkit the apps use, so they added the needed signal handling themselves.

    Comment


    • #42
      Originally posted by bug77 View Post

      That's not the difference. The difference is Microsoft owns the toolkit the apps use, so they added the needed signal handling themselves.
      And people using Linux don't "own" it? As I know it's opensource and people can add features they miss. In fact, they do that - e.g. the security workarounds around X11, alternatives to Wayland and adding features to GUI toolkits. On the other hand, MS can own whatever they want, but it's for nothing if developers don't use it. (On the other hand on Linux, the one with biggest workforce wins, because their solution is developed the fastest and devs of alternatives lose desire to continue.)

      Comment


      • #43
        Originally posted by Ladis View Post

        And people using Linux don't "own" it? As I know it's opensource and people can add features they miss. In fact, they do that - e.g. the security workarounds around X11, alternatives to Wayland and adding features to GUI toolkits. On the other hand, MS can own whatever they want, but it's for nothing if developers don't use it. (On the other hand on Linux, the one with biggest workforce wins, because their solution is developed the fastest and devs of alternatives lose desire to continue.)
        I meant Microsoft own the whole stack. When they add signals (or whatever) to their DE, they can add signals processing to the toolkit in one go.
        On Linux, you have to add the signals to X or Wayland (or both, but I think that rarely happens). If it's Wayland, you have to get the implementations to start emitting those signals. And then you have to teach both Qt and Gtk+ to handle them. Not impossible, in some cases it could be the same guys doing the work albeit having to work with several teams/projects. It's certainly going to take a lot more time to market.

        Comment

        Working...
        X