6 ms·

"Gnome (and Wayland) is broken, and this API must be changed." Again I would say no, that's wrong, it's just not currently meant to run on your hardware. If yo

by md8z 5y ago

"Gnome (and Wayland) is broken, and this API must be changed." Again I would say no, that's wrong, it's just not currently meant to run on your hardware. If you know how to change this API then please help. AFAIK there is no one working on this currently. To solve the problem, it really needs someone who is committed to getting it working on the type of hardware that you have and who can champion that use case. If that's not you then you'll have to wait (indefinitely) until that person shows up, if they do at all. Also, shadertoy is a really bad test case as those are more like demos, they aren't optimized and are just made to show how much you can do by computing things on the fly in a shader. A real program you'd see in production would make better use of GPU memory and wouldn't hammer the GPU cores so hard.

nextaccountic 5y ago
> "Gnome (and Wayland) is broken, and this API must be changed." > Again I would say no, that's wrong, it's just not currently meant to run on your hardware. It' absurd that not running on common hardware is, somehow, not broken.
kuschku 5y ago
What’s so complicated about just copying Windows, Android or Qt 1:1? I’ve got all my time already full with jobs, projects, and other stuff I’m working on, if I’d find time, I’d love to help extending wayland, deprecating GTK3 and GTK4, and modifying the software accordingly. I’ve made custom patches for the same purpose in the past already, but I just don’t have the time. Especially since with X11 it was at least somewhat possible to do it, but now with wayland it’s sadly enforced in the protocol to only use 8-bit sRGB and integer scale factors. If I ever find the person responsible for that decision...
- vetinari 5y ago
  Android started with it from the start and developers were aware of it. Windows and Qt were retrofitted and it shows. Both are buggy and unreliable.
- md8z 5y ago
  It's not hard to copy an API specification, but actually implementing the API and changing drawing in every app, toolkit and compositor to support floating point is what is going to be complicated and will take time. Edit: The decision to use integer coordinates I believe was made long ago in GTK1 because that's what X11 used, and it just hasn't been changed since. "Especially since with X11 it was at least somewhat possible to do it" X11 never actually supported this and also only uses integers for screen and input coordinates so I'm not sure what you're referring to. I think you are thinking of the app itself doing its own DPI scaling which will also work in wayland, but it will have the same problems where the DPI could mismatch with other apps and with the rest of the desktop. "I’d love to help extending wayland, deprecating GTK3 and GTK4" Well GTK3 is already in maintenance mode, and apps are currently in the process of being ported to GTK4, so first they'll probably want to finish that and get some feedback before starting on GTK5... it will probably be at least a few years before anything related to this could ship.
  - kuschku 5y ago
    GTK2 had an integer DPI variable. GTK3 now just has an integer scale variable. GTK2 could actually render at 144dpi, or 108dpi, just fine. Everything was slightly misaligned, not everything scaled perfectly, but it worked. X11 had an integer Xft.dpi variable. Wayland now just has an integer scale variable. WHY was this downgrade made? If a protocol break could be made to remove this functionality, a protocol break to add it back should be just as justified. Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well. Yes, I am extremely angry after having spent years yelling at the wayland-wg and gnome devs not to make these decisions, not to put these things into the protocol, and complaining that if an API break is necessary, it should be extensible for these use cases. I’ve been complaining for a decade now and all of the complaints got ignored and instead the mistakes I warned about were made.
    - vetinari 5y ago
      > GTK2 could actually render at 144dpi, or 108dpi, just fine. Your definition for just fine must differ from everyone's else. Most GTK2 shipped assets for 96 dpi and that's it. Just try running GIMP on 192 dpi display, with "properly set dpi", for example. You will see yourself that is was not just fine. > WHY was this downgrade made? Because it didn't work. That's why. > If a protocol break could be made to remove this functionality It wasn't protocol break. It was apps either ignoring the facilities (in better case) or being outright broken -> desktop locking on constant values, where everyone was able to test their wares. > protocol break to add it back should be just as justified. Not going to happen. > Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well. You can start. Show 'em.

by md8z 5y ago

nextaccountic 5y ago

> "Gnome (and Wayland) is broken, and this API must be changed." > Again I would say no, that's wrong, it's just not currently meant to run on your hardware. It' absurd that not running on common hardware is, somehow, not broken.

kuschku 5y ago

What’s so complicated about just copying Windows, Android or Qt 1:1? I’ve got all my time already full with jobs, projects, and other stuff I’m working on, if I’d find time, I’d love to help extending wayland, deprecating GTK3 and GTK4, and modifying the software accordingly. I’ve made custom patches for the same purpose in the past already, but I just don’t have the time. Especially since with X11 it was at least somewhat possible to do it, but now with wayland it’s sadly enforced in the protocol to only use 8-bit sRGB and integer scale factors. If I ever find the person responsible for that decision...

vetinari 5y ago
Android started with it from the start and developers were aware of it. Windows and Qt were retrofitted and it shows. Both are buggy and unreliable.
md8z 5y ago
It's not hard to copy an API specification, but actually implementing the API and changing drawing in every app, toolkit and compositor to support floating point is what is going to be complicated and will take time. Edit: The decision to use integer coordinates I believe was made long ago in GTK1 because that's what X11 used, and it just hasn't been changed since. "Especially since with X11 it was at least somewhat possible to do it" X11 never actually supported this and also only uses integers for screen and input coordinates so I'm not sure what you're referring to. I think you are thinking of the app itself doing its own DPI scaling which will also work in wayland, but it will have the same problems where the DPI could mismatch with other apps and with the rest of the desktop. "I’d love to help extending wayland, deprecating GTK3 and GTK4" Well GTK3 is already in maintenance mode, and apps are currently in the process of being ported to GTK4, so first they'll probably want to finish that and get some feedback before starting on GTK5... it will probably be at least a few years before anything related to this could ship.
- kuschku 5y ago
  GTK2 had an integer DPI variable. GTK3 now just has an integer scale variable. GTK2 could actually render at 144dpi, or 108dpi, just fine. Everything was slightly misaligned, not everything scaled perfectly, but it worked. X11 had an integer Xft.dpi variable. Wayland now just has an integer scale variable. WHY was this downgrade made? If a protocol break could be made to remove this functionality, a protocol break to add it back should be just as justified. Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well. Yes, I am extremely angry after having spent years yelling at the wayland-wg and gnome devs not to make these decisions, not to put these things into the protocol, and complaining that if an API break is necessary, it should be extensible for these use cases. I’ve been complaining for a decade now and all of the complaints got ignored and instead the mistakes I warned about were made.
  - vetinari 5y ago
    > GTK2 could actually render at 144dpi, or 108dpi, just fine. Your definition for just fine must differ from everyone's else. Most GTK2 shipped assets for 96 dpi and that's it. Just try running GIMP on 192 dpi display, with "properly set dpi", for example. You will see yourself that is was not just fine. > WHY was this downgrade made? Because it didn't work. That's why. > If a protocol break could be made to remove this functionality It wasn't protocol break. It was apps either ignoring the facilities (in better case) or being outright broken -> desktop locking on constant values, where everyone was able to test their wares. > protocol break to add it back should be just as justified. Not going to happen. > Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well. You can start. Show 'em.