3 ms·

I don't get why performance degradations are accepted though. I do most of my computing on old hardware and these are features I would turn off if I could and p

I don't get why performance degradations are accepted though. I do most of my computing on old hardware and these are features I would turn off if I could and perhaps are not even supported by my gpus.

flohofwoe 3y ago
In GL it's quite easy to accidentially miss the "fast path" and get surprising slowdowns (and in reverse, GL can be surprisingly fast when hitting the fast path). What's disappointing though is that the Vulkan renderer only nearly reaches the same performance as the old GL renderer, this seems to indicate that the problem sits on the caller side of the 3D API. It would probably have been a good idea to track performance throughout the implementation and iterate on that instead of "architectural purity".
- Vinnl 3y ago
  I don't understand half of the post, but claiming that they're doing this for "architectural purity" sounds ungenerous to me. The post lists a couple of tangible benefits, most of which do, I believe, relate to performance: > Proper color handling (including HDR) > Path rendering on the GPU > Possibly including glyph rendering > Off-the-main-thread rendering > Performance (on old and less powerful devices) (Which is not to say that tracking performance isn't a good idea. It's just that "architectural purity" sounds needlessly dismissive to me.)
ahartmetz 3y ago
These renderers are not on by default and likely never will be. I have never seen it work that an immediate mode rendering API translated to retained mode becomes faster. It is probably somehow possible, but will require a ton of work and probably changes on the API client side to fix some pathological cases.
- mananaysiempre 3y ago
  > I have never seen it work that an immediate mode rendering API translated to retained mode becomes faster. I don’t think I get your point here. Gtk 4 is retained-mode whatever renderer you use; Vulkan and OpenGL are immediate-mode (well, kinda) whatever renderer you use. Whatever problems that forces in the new renderers would be just as present in the old ones, wouldn’t they?
  - ahartmetz 3y ago
    Oh, you are right about GTK4! It has switched to a scene graph and retained mode drawing. Somehow, I had never heard of that before. Presumably, it was done to be able to use 3D graphics APIs that all work in retained mode. Vulkan and OpenGL, though, are in no practical sense immediate mode: You need to draw the whole frame every frame (barring a few exotic extensions for compositors and such), so you need to retain the state of everything in the frame so you can draw it.
    - epcoa 3y ago
      Your usage of these terms in completely unconventional and wacky. > You need to draw the whole frame every frame This isn’t even true at a high level. You can composite buffers. That’s not exotic. That’s a fundamental operation. But insofar as needing to actually do all your draw calls at once - that is literally what "immediate" in immediate mode means. > Vulkan and OpenGL They don’t specifically retain state - they’re immediate. That’s what immediate mode means. What something higher up does has nothing to do with it. What would you even consider immediate mode by your definition? > so you need to retain the state of everything in the frame so you can draw it. That state can be a procedure and a handful of variables (which in the extreme is all a shader). The point is Vulkan and OpenGL have no say over the nature of that state.
      - ahartmetz 3y ago
        OK, so sorry, I was misusing the terms. I guess I'm looking at it from a GUI application programmer POV. That OpenGL or Vulkan are, themselves, immediate mode, doesn't matter all that much there. Drawing happens on the GPU, which wants to process large buffers without changing its state in between. An overview of all drawing operations (scene graph, proper use of the term retained mode) with batching and merging is needed to cater to that. Examples: Qt QML scene graph, GTK4 GSK > You can composite buffers Compositing buffers is still drawing, though > What would I consider immediate mode? Basically, a canvas-type thing. You just scribble wherever whenever (limited by convention and correctness, of course) and what you don't touch stays like it is. Drawing happens on the CPU, which is fairly happy to do small operations at the drop of a hat. No need to remember any state for the benefit of the graphics API. Examples: Qt QPainter, GTK < 4 using Cairo
ho_schi 3y ago
> No, the new renderers are not faster (yet). I think yet is here the important word. If you see a noticeable performance decrease: > GSK_RENDERER=gl Please keep in mind that it is unlikely that Microsoft, Apple or Google would discuss these. It would be probably „forget the old API, here another API“ (Microsoft), „enforced from ${WEIRD_NAME}“ (Apple) or „you won’t get that update“ (Google).
- BlueTemplar 3y ago
  Yeah, reminds me of Grinding Gear Games (Tencent for a few years now) where if you read the update notes for Path of Exile 1, you can see "performance improvements" mentioned many times, yet, mysteriously, the game today has effective minimal requirements order(s) of magnitude (if multiplied together) higher than on release !
unleaded 3y ago
GNOME dev team (and by extension GTK) probably don't care that much, iirc most of them use expensive macbooks so many issues get ignored because it "Works on my machine" (e.g. several issues with font rendering that don't affect retina displays)
- amaranth 3y ago
  The font rendering thing is more complicated than that. Subpixel antialiasing doesn't work with animations and I'm pretty sure it interacts poorly with fractional scaling too. The fact that you don't need subpixel antialiasing if you have a HiDPI display just lets them make the tradeoff be "you need a good monitor" instead of having to choose between jaggy text or weird shimmering on animations.
  - tuna74 3y ago
    Also, it is impossible to know which subpixel structure the user has.
    - unleaded 3y ago
      asking them doesn't count? https://i.stack.imgur.com/g2auK.png https://i.stack.imgur.com/g2auK.png
      - tuna74 3y ago
        Users might like the "wrong" look. Also, what happens if you connect a new screen or just rotate your current screen?
ComputerGuru 3y ago
This is actually the only case where I tolerate performance regressions: where the previous implementation was actually incorrect, rather than merely old or in need of a rewrite in whatever framework or technology is currently in vogue.
- taeric 3y ago
  Performance is part of the implementation. Therefore, if it regresses, it is silly to claim it was incorrect before. Seems more likely to claim that tradeoffs were made for performance. I'm ok with performance leaning on advances in the hardware. I'm also ok with performance dropping if you are pushing more pixels. But, we had high resolution displays years ago. Such that that is a tough hill to defend.
  - ComputerGuru 3y ago
    Performance is a combination of a) required behavior, b) implementation. If an implementation does not correctly meet the requirements, its performance cannot be compared to one that does.
    - taeric 3y ago
      Close. Performance is also part of your "a", there. And you have to adjust implementation accordingly. Is why nobody says that old "3d" games like Doom were poorly implemented. Even if they were not fully 3d.
      - ComputerGuru 3y ago
        Sure. But I'm approaching this from the assumption that we're actually talking "observed/resultant performance" and not "baseline required performance," i.e. talking about "'excess' performance over the required threshold," and if that regresses due to a correctness issue, I don't see the problem. Now what is "the minimum required performance threshold," I cannot say, but it is surely at least the ability to render on "CPU" at 60Hz. (which CPU? render what? using how much of the available CPU power? with how many frames of latency allowed?) Note that I don't fundamentally disagree with you and I cringe when I hear issues dismissed as "premature optimizations" myself.

flohofwoe 3y ago

In GL it's quite easy to accidentially miss the "fast path" and get surprising slowdowns (and in reverse, GL can be surprisingly fast when hitting the fast path). What's disappointing though is that the Vulkan renderer only nearly reaches the same performance as the old GL renderer, this seems to indicate that the problem sits on the caller side of the 3D API. It would probably have been a good idea to track performance throughout the implementation and iterate on that instead of "architectural purity".

Vinnl 3y ago
I don't understand half of the post, but claiming that they're doing this for "architectural purity" sounds ungenerous to me. The post lists a couple of tangible benefits, most of which do, I believe, relate to performance: > Proper color handling (including HDR) > Path rendering on the GPU > Possibly including glyph rendering > Off-the-main-thread rendering > Performance (on old and less powerful devices) (Which is not to say that tracking performance isn't a good idea. It's just that "architectural purity" sounds needlessly dismissive to me.)

ahartmetz 3y ago

These renderers are not on by default and likely never will be. I have never seen it work that an immediate mode rendering API translated to retained mode becomes faster. It is probably somehow possible, but will require a ton of work and probably changes on the API client side to fix some pathological cases.

mananaysiempre 3y ago
> I have never seen it work that an immediate mode rendering API translated to retained mode becomes faster. I don’t think I get your point here. Gtk 4 is retained-mode whatever renderer you use; Vulkan and OpenGL are immediate-mode (well, kinda) whatever renderer you use. Whatever problems that forces in the new renderers would be just as present in the old ones, wouldn’t they?
- ahartmetz 3y ago
  Oh, you are right about GTK4! It has switched to a scene graph and retained mode drawing. Somehow, I had never heard of that before. Presumably, it was done to be able to use 3D graphics APIs that all work in retained mode. Vulkan and OpenGL, though, are in no practical sense immediate mode: You need to draw the whole frame every frame (barring a few exotic extensions for compositors and such), so you need to retain the state of everything in the frame so you can draw it.
  - epcoa 3y ago
    Your usage of these terms in completely unconventional and wacky. > You need to draw the whole frame every frame This isn’t even true at a high level. You can composite buffers. That’s not exotic. That’s a fundamental operation. But insofar as needing to actually do all your draw calls at once - that is literally what "immediate" in immediate mode means. > Vulkan and OpenGL They don’t specifically retain state - they’re immediate. That’s what immediate mode means. What something higher up does has nothing to do with it. What would you even consider immediate mode by your definition? > so you need to retain the state of everything in the frame so you can draw it. That state can be a procedure and a handful of variables (which in the extreme is all a shader). The point is Vulkan and OpenGL have no say over the nature of that state.
    - ahartmetz 3y ago
      OK, so sorry, I was misusing the terms. I guess I'm looking at it from a GUI application programmer POV. That OpenGL or Vulkan are, themselves, immediate mode, doesn't matter all that much there. Drawing happens on the GPU, which wants to process large buffers without changing its state in between. An overview of all drawing operations (scene graph, proper use of the term retained mode) with batching and merging is needed to cater to that. Examples: Qt QML scene graph, GTK4 GSK > You can composite buffers Compositing buffers is still drawing, though > What would I consider immediate mode? Basically, a canvas-type thing. You just scribble wherever whenever (limited by convention and correctness, of course) and what you don't touch stays like it is. Drawing happens on the CPU, which is fairly happy to do small operations at the drop of a hat. No need to remember any state for the benefit of the graphics API. Examples: Qt QPainter, GTK < 4 using Cairo

ho_schi 3y ago

> No, the new renderers are not faster (yet). I think yet is here the important word. If you see a noticeable performance decrease: > GSK_RENDERER=gl Please keep in mind that it is unlikely that Microsoft, Apple or Google would discuss these. It would be probably „forget the old API, here another API“ (Microsoft), „enforced from ${WEIRD_NAME}“ (Apple) or „you won’t get that update“ (Google).

BlueTemplar 3y ago
Yeah, reminds me of Grinding Gear Games (Tencent for a few years now) where if you read the update notes for Path of Exile 1, you can see "performance improvements" mentioned many times, yet, mysteriously, the game today has effective minimal requirements order(s) of magnitude (if multiplied together) higher than on release !

unleaded 3y ago

GNOME dev team (and by extension GTK) probably don't care that much, iirc most of them use expensive macbooks so many issues get ignored because it "Works on my machine" (e.g. several issues with font rendering that don't affect retina displays)

amaranth 3y ago
The font rendering thing is more complicated than that. Subpixel antialiasing doesn't work with animations and I'm pretty sure it interacts poorly with fractional scaling too. The fact that you don't need subpixel antialiasing if you have a HiDPI display just lets them make the tradeoff be "you need a good monitor" instead of having to choose between jaggy text or weird shimmering on animations.
- tuna74 3y ago
  Also, it is impossible to know which subpixel structure the user has.
  - unleaded 3y ago
    asking them doesn't count? https://i.stack.imgur.com/g2auK.png https://i.stack.imgur.com/g2auK.png
    - tuna74 3y ago
      Users might like the "wrong" look. Also, what happens if you connect a new screen or just rotate your current screen?

ComputerGuru 3y ago

This is actually the only case where I tolerate performance regressions: where the previous implementation was actually incorrect, rather than merely old or in need of a rewrite in whatever framework or technology is currently in vogue.

taeric 3y ago
Performance is part of the implementation. Therefore, if it regresses, it is silly to claim it was incorrect before. Seems more likely to claim that tradeoffs were made for performance. I'm ok with performance leaning on advances in the hardware. I'm also ok with performance dropping if you are pushing more pixels. But, we had high resolution displays years ago. Such that that is a tough hill to defend.
- ComputerGuru 3y ago
  Performance is a combination of a) required behavior, b) implementation. If an implementation does not correctly meet the requirements, its performance cannot be compared to one that does.
  - taeric 3y ago
    Close. Performance is also part of your "a", there. And you have to adjust implementation accordingly. Is why nobody says that old "3d" games like Doom were poorly implemented. Even if they were not fully 3d.
    - ComputerGuru 3y ago
      Sure. But I'm approaching this from the assumption that we're actually talking "observed/resultant performance" and not "baseline required performance," i.e. talking about "'excess' performance over the required threshold," and if that regresses due to a correctness issue, I don't see the problem. Now what is "the minimum required performance threshold," I cannot say, but it is surely at least the ability to render on "CPU" at 60Hz. (which CPU? render what? using how much of the available CPU power? with how many frames of latency allowed?) Note that I don't fundamentally disagree with you and I cringe when I hear issues dismissed as "premature optimizations" myself.