Hacker News Reader

Comment by bjourne | Hacker News Reader

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.

View on HN

    > 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).

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 !

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".

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.)

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.

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.

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.

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.

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.

I think that is fair. I was approaching this from the perspective of "my old machine was responsive, it is becoming less so." Back on the example of Doom, I understood why my machine at the time couldn't run Quake. It would be frustrating to force everyone to that paradigm.

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.

> 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?

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.

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.

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

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)

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.

Also, it is impossible to know which subpixel structure the user has.

asking them doesn't count? https://i.stack.imgur.com/g2auK.png

Users might like the "wrong" look. Also, what happens if you connect a new screen or just rotate your current screen?

Reply on news.ycombinator.com