4 ms·

Dynamic triple buffering for GNOME has been postponed again, fractional scaling is nowhere in sight, but they landed > a new workspace switcher and a much-impr

by reisse 3y ago

Dynamic triple buffering for GNOME has been postponed again, fractional scaling is nowhere in sight, but they landed > a new workspace switcher and a much-improved image viewer. What a joke of a product management. Sometimes I envy guys who can rewrite workspace switchers again and again on Red Hat's money.

dilap 3y ago
Do you envy Sisyphus? Very similar situation, I think.
- eVeechu7 3y ago
  Sisyphus only has one rock to worry about.
kcb 3y ago
And still lacking VRR support. All we have is this needlessly drama laden multi-year MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
- reisse 3y ago
  Oh, I forgot about that! Thanks for the reminder. And lacking VRR is even more insulting now, since SteamOS has a working implementation for Wayland. Given how much Valve is doing for desktop Linux, I guess one day SteamOS will be the default distribution.
deafpolygon 3y ago
In my excitement with the beta version of Fedora 39, I installed it and had fractional scaling for a few minutes- until I installed updates and rebooted. It was gone. That was the last time I touched it. Fractional Scaling is a *must* these days, with the high res laptop screens.
phendrenad2 3y ago
Even though Linux is open-source, it's not immune to the force of money. There are paying customers for Red Hat, and maybe they don't care about DPI scaling that much.
- jsiepkes 3y ago
  Modern high-res screens in notebooks are almost unusable with Gnome. You need to enable "Large fonts" under accessibility to make it remotely usable. And these screens are becoming more common. So where do paying Red Hat customers use Gnome for then if it's not on notebooks and desktops? For servers?
  - phendrenad2 3y ago
    That seems likely, yes
    - Ckirby 3y ago
      Mostly severs yes, desktop Linux died somewhere around 2010.
  - ahgshando6698 3y ago
    [dead]
- reisse 3y ago
  I doubt any of Red Hat paying customers are caring about image viewers or other important GNOME improvements in this release.
  - tristan957 3y ago
    Red Hat didn't work on the image viewer. Why do you keep making comments on things you are uninformed on?
    - phendrenad2 3y ago
grigio 3y ago
I can't believe LOL!
tristan957 3y ago
How many people do you think Red Hat pays to work on all projects within the GNOME namespace on their GitLab? There were no Red Hat employees involved in the development of the new image viewer. It was a community effort. Will you be stepping up to provide resources? Why are you ignoring all the other work Red Hat did this cycle with regard to things like HDR?
- t0bia_s 3y ago
  Does Fedora 39 support 10bit displays finally?
yoyohello13 3y ago
The amount of back seat dev that happens whenever Gnome does anything is amazing. You have no idea what the challenges are or how the development process works for this project. The workspace switcher could just be some drive by PR, who knows. Tripple buffering and fractional scaling are hard problems. If you don't think so, feel free to show them how it's done and implement it yourself.
- reisse 3y ago
  > You have no idea what the challenges are or how the development process works for this project. The magic of the open source gives you the possibility to see it. And I do sometimes take a look into a shitshow of management which is this three years old triple buffering MR [1]. Don't get me wrong, I didn't examine the code thoroughly, it might be a marvel of engineering, but when it takes you more than three years (and counting!) to land a feature, to the point where some people start to forgot why it was even necessary in the first place [2], and when downstream has to monkey-patch your feature as-is because the benefits are so big [3], you cannot say your development processes are alright. And it's not only triple buffering, you can see the same pattern in the MR for VRR [4]. 1. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 2. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#note_1803686 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#... 3. https://discourse.ubuntu.com/t/why-ubuntu-22-04-is-so-fast-and-how-to-make-it-faster/30369 https://discourse.ubuntu.com/t/why-ubuntu-22-04-is-so-fast-a... 4. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
  - tuna74 3y ago
    You can see a lot of bugs found (and being fixed) in that MR. Should Gnome add lots of new bugs for little gain?
    - reisse 3y ago
      I won't answer this question because Canonical did it for me. As I mentioned in the parent post, they considered the gain so important that Ubuntu ships triple buffering patch starting from 22.04 LTS. Well, they actually come up with this feature - Daniel Van Vugt, author of the patch (huuuuge thank you, by the way) works for Canonical. So yeah, I promised not to answer, but I'd say GNOME should definitely have upstreamed the changes much earlier.

by reisse 3y ago

dilap 3y ago

Do you envy Sisyphus? Very similar situation, I think.

eVeechu7 3y ago
Sisyphus only has one rock to worry about.

kcb 3y ago

And still lacking VRR support. All we have is this needlessly drama laden multi-year MR https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154

reisse 3y ago
Oh, I forgot about that! Thanks for the reminder. And lacking VRR is even more insulting now, since SteamOS has a working implementation for Wayland. Given how much Valve is doing for desktop Linux, I guess one day SteamOS will be the default distribution.

deafpolygon 3y ago

In my excitement with the beta version of Fedora 39, I installed it and had fractional scaling for a few minutes- until I installed updates and rebooted. It was gone. That was the last time I touched it. Fractional Scaling is a *must* these days, with the high res laptop screens.

phendrenad2 3y ago

Even though Linux is open-source, it's not immune to the force of money. There are paying customers for Red Hat, and maybe they don't care about DPI scaling that much.

jsiepkes 3y ago
Modern high-res screens in notebooks are almost unusable with Gnome. You need to enable "Large fonts" under accessibility to make it remotely usable. And these screens are becoming more common. So where do paying Red Hat customers use Gnome for then if it's not on notebooks and desktops? For servers?
- phendrenad2 3y ago
  That seems likely, yes
  - Ckirby 3y ago
    Mostly severs yes, desktop Linux died somewhere around 2010.
- ahgshando6698 3y ago
  [dead]
reisse 3y ago
I doubt any of Red Hat paying customers are caring about image viewers or other important GNOME improvements in this release.
- tristan957 3y ago
  Red Hat didn't work on the image viewer. Why do you keep making comments on things you are uninformed on?
  - phendrenad2 3y ago

grigio 3y ago

I can't believe LOL!

tristan957 3y ago

How many people do you think Red Hat pays to work on all projects within the GNOME namespace on their GitLab? There were no Red Hat employees involved in the development of the new image viewer. It was a community effort. Will you be stepping up to provide resources? Why are you ignoring all the other work Red Hat did this cycle with regard to things like HDR?

t0bia_s 3y ago
Does Fedora 39 support 10bit displays finally?

yoyohello13 3y ago

The amount of back seat dev that happens whenever Gnome does anything is amazing. You have no idea what the challenges are or how the development process works for this project. The workspace switcher could just be some drive by PR, who knows. Tripple buffering and fractional scaling are hard problems. If you don't think so, feel free to show them how it's done and implement it yourself.

reisse 3y ago
> You have no idea what the challenges are or how the development process works for this project. The magic of the open source gives you the possibility to see it. And I do sometimes take a look into a shitshow of management which is this three years old triple buffering MR [1]. Don't get me wrong, I didn't examine the code thoroughly, it might be a marvel of engineering, but when it takes you more than three years (and counting!) to land a feature, to the point where some people start to forgot why it was even necessary in the first place [2], and when downstream has to monkey-patch your feature as-is because the benefits are so big [3], you cannot say your development processes are alright. And it's not only triple buffering, you can see the same pattern in the MR for VRR [4]. 1. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441 2. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#note_1803686 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441#... 3. https://discourse.ubuntu.com/t/why-ubuntu-22-04-is-so-fast-and-how-to-make-it-faster/30369 https://discourse.ubuntu.com/t/why-ubuntu-22-04-is-so-fast-a... 4. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154 https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
- tuna74 3y ago
  You can see a lot of bugs found (and being fixed) in that MR. Should Gnome add lots of new bugs for little gain?
  - reisse 3y ago
    I won't answer this question because Canonical did it for me. As I mentioned in the parent post, they considered the gain so important that Ubuntu ships triple buffering patch starting from 22.04 LTS. Well, they actually come up with this feature - Daniel Van Vugt, author of the patch (huuuuge thank you, by the way) works for Canonical. So yeah, I promised not to answer, but I'd say GNOME should definitely have upstreamed the changes much earlier.