There's also good reasons that immediate mode GUIs are largely only ever used by games, they are absolutely terrible for regular UI needs. Since Rust gaming is still largely non-existent, it's hardly surprising that things like 'egui' are similarly struggling. That doesn't (or shouldn't) be any reflection on whether or not Rust GUIs as a whole are struggling.
Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs...
For Edge and Chrome I'm surprised it doesn't work for you with HDR enabled in the OS, but did you by chance turn the SDR brightness all the way up in the OS settings as well? Since desktop OLED displays are not very bright you might have done this. And if so then there's simply no more brightness range left for HDR to use, so you basically have an SDR display at that point regardless.
That said, Windows also has by far the worst HDR support of any platform. Possibly because they were one of the first so everyone else got to learn from their mistakes, but they also haven't seemingly tried to fix it, either, which is odd
They don't. It's your eyes re-calibrating to something brighter showing up. The brightness of the SDR content didn't actually change, just like it doesn't when someone turns on the lights in the room even though it ends up appearing darker.
The perceptual issue of simultaneous contrast ( https://en.wikipedia.org/wiki/Contrast_effect ) is a much bigger problem with HDR content in general than people tend to consider. There's far too much HDR content out there that just slams the brightness because it can, essentially resulting in just being an SDR video that had the brightness cranked. Nearly all mobile HDR video falls into this category in particular.
This is not helped at all by the fact that prior to the introduction of gainmaps in images, which many slammed as "a hack" or "not true HDR", the mapping between HDR and SDR values was undefined. BT2048 has attempted to retroactively define that PQ & HLG at "203 nits" maps to "graphics white" (aka, SDR white), but almost nothing is authored to this expectation. The huge advancement of gainmaps, beyond per-pixel local tonemapping, was that the mapping between SDR & HDR was rigidly defined by the spec. So you could actually author content that could be displayed next to SDR content without destroying people's eyes.
I was initially hopeful about HDR but when I found out how it was implemented I thought: that's a way to make certain that both the SDR and HDR versions will look wrong every time.
WebGPU has the problem of needing to handle the lowest common denominator (so GLES 3 if not GLES 2 because of low end mobile), and also needing to deal with Apple's refusal to do anything with even a hint of Khronos (hence why no SPIR-V even though literally everything else including DirectX has adopted it)
Web graphics have never and will never be cutting edge, they can't as they have to sit on top of browsers that have to already have those features available to it. It can only ever build on top of something lower level. That's not inherently bad, not everything needs cutting edge, but "it's outdated" is also just inherently going to be always true.
I understand not being cutting-edge. But having a feature-set from 2010 is...not great.
Also, some things could have easily be done different and then be implemented as efficient as a particular backend allows. Like pipelines. Just don't do pipelines at all. A web graphics API does not need them, WebGL worked perfectly fine without them. The WebGPU backends can use them if necessary, or not use them if more modern systems don't require them anymore. But now we're locked-in to a needlessly cumbersome and outdated way of doing things in WebGPU.
Similarly, WebGPU could have done without that static binding mess. Just do something like commandBuffer.draw(shader, vertexBuffer, indexBuffer, texture, ...) and automatically connect the call with the shader arguments, like CUDA does. The backend can then create all that binding nonsense if necessary, or not if a newer backend does not need it anymore.
Except it didn't. In the GL programming model it's trivial to accidentially leak the wrong granular render state into the next draw call, unless you always reconfigure all states anyway (and in that case PSOs are strictly better, they just include too much state).
The basic idea of immutable state group objects is a good one, Vulkan 1.0 and D3D12 just went too far (while the state group granularity of D3D11 and Metal is just about right).
> Similarly, WebGPU could have done without that static binding mess.
This I agree with, pre-baked BindGroup objects were just a terrible idea right from the start, and AFAIK they are not even strictly necessary when targeting Vulkan 1.0.
There should be a better abstraction to solve the GL state leakage problem than PSOs. We end up with a combinatory explosion of PSOs when some states they abstract are essentially toggling some bits in a GPU register in no way coupled with the rest of the pipeline state.
That abstraction exists in D3D11 and to a lesser extent in Metal via smaller state-group-objects (for instance D3D11 splits the rende state into immutable objects for rasterizer-state, depth-stencil-state, blend-state and (vertex-)input-layout-state (not even needed anymore with vertex pulling).
Even if those state group objects don't match the underlying hardware directly they still reign in the combinatorial explosion dramatically and are more robust than the GL-style state soup.
AFAIK the main problem is state which needs to be compiled into the shader on some GPUs while other GPUs only have fixed-function hardware for the same state (for instance blend state).
> Except it didn't. In the GL programming model it's trivial to accidentially leak the wrong granular render state into the next draw call
This is where I think Vulkan and WebGPU are chasing the wrong goal: To make draw calls faster. What's even faster, however, is making fewer draw calls and that's something graphics devs can easily do when you provide them with tools like multi-draw. Preferably multi-draw that allows multiple different buffers. Doing so will naturally reduce costly state changes with little effort.
Politics is simply how a society governs itself. Whether or not a society values the rules being enforce to rulers is itself politics. Dismissing politics like this is how we end up with exactly the problem of rules not applying to rulers.
Get involved with politics. Be part of politics. That is how freedom is earned & maintained.
We don't consider warehouses & stores to be a "slippery slope" away from toll roads, so no I really don't see any good faith slippery slope argument that connects enforcing the law against X to be the same as government censorship of ISPs.
I mean even just calling it censorship is already trying to shove a particular bias into the picture. Is it government censorship that you aren't allowed to shout "fire!" in a crowded theater? Yes. Is that also a useful feature of a functional society? Also yes. Was that a "slippery slope"? Nope. Turns out people can handle that nuance just fine.
I wonder if sudo would be better off joining one of those open source foundations instead of staying solo. It's too small to justify a meaningful amount of contribution to these companies, at which point the bureaucratic overhead of dealing with it probably kills the motivation
This is what I've never understood about Apple's argument that they need to be compensated for the R&D and ops costs of running the App Store. They already have this! It's the developer program fee!!
As far as I can tell it wasn't even raised in the Epic case either.
I don't think that applies to Patreon which, as far as I know, doesn't have any ads in the first place?
The app might make it easier for them to enforce DRM-like behaviors to prevent people from pirating creators content, but I strongly suspect people aren't doing that on iOS regardless.
> given that we already had a working GUI. (Maybe that was the intention.)
Neither X11 nor Wayland provide a GUI. Your GUI is provided by GTK or QT or TCL or whatever. X11 had primitive rendering instructions that allowed those GUIs to delegate drawing to a central system service, but very few things do that anymore anyway. Meaning X11 is already just a dumb compositor in practice, except it's badly designed to be a dumb compositor because that wasn't its original purpose. As such, Wayland is really just aligning the protocol to what clients actually want & do.
Unless the Rust ecosystem made the easily predicted terrible choice of rallying behind immediate mode GUIs for generic UIs...
reply