ben-schaaf

Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region.

The way this is done everywhere is to invalidate the entire area of the button. Buttons usually change background on hover/click anyway, so it just doesn't make sense to do more. Text input is special because these widgets can be very large, sometimes spanning the whole screen, so you want fine-grained dirty regions.

Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.

I've never heard of anyone adding a general Widget-Level cache, considering that most UI elements don't change position that would be quite expensive. In any case the rendering is still a "pure" function regardless of whether you're using dirty regions or not, so not sure what you're trying to say here.

Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.

That is definitely weird, but it still clearly shows that the regions are being tracked.

That doesn't mean that the process stops, it runs indefinitely because it has to.

The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.

The DOM does this. React does this.

What does react have to do with any of this discussion, and what do you mean by "this"?

Did you know CSS even invokes the GPU for certain tasks?

Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.

You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.

Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.

Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.

Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.

This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible.

For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering.

Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.

Blender has multiple options for emulating a middle mouse button. I can use blender just fine on my laptop with a touchpad.

As for the numpad you can use the tilde key or alt+drag to switch views. There's also a handy gizmo.

Arc Raiders is a great example for why UE5 is the reason games run poorly. It neither uses Nanite nor Lumen. Valorant goes even further and uses a custom forward renderer. The studios that care about performance avoid using the big headline features of UE5.

Benchmarks are easy to find. The basic M1 has double the single core performance over the Ampere Altra Max: https://www.cpubenchmark.net/compare/6915vs4104/Ampere-Altra...

I find it's incredibly helpful to know when someone's using an automated translator, as they usually get details wrong while still reading like a native speaker. Not using a translator at all, or disclosing that one was used means I can make a better educated guess as to what they mean. It also changes how I reply.

Compared to that Toyota the sightlines are objectively worse with the longer hood. Using the comparison cars the hood stands at 1.12m before the sloped part; a 6 year old could easily stand in front of that and you'd never see them.

Compared to a Toyota corolla, there's at least a 50% higher fatality risk in pedestrian accidents solely from the higher hood. That's for the general population. Given how these fatalities usually work, the risk to children is exponentially higher. There are dozens of studies on this.

No, this car isn't the worse offender, but lets not forget the important part here: This hood design is exclusively done for aesthetics.

Yet it still has a relatively tall, straight hood that tends to drag people underneath the car. These designs are terrible in pedestrian accidents; to a significantly greater degree when children are involved.

Every iphone, ipad, playstation, xbox, android phone (though there are ways of unlocking), smart TV, smart Fridge. These are all devices that run a full web browser, these aren't appliances they're full personal computers. You can write and run software on them, even if arbitrarily limited in hardware access.

Funneling means opening up the device for the entire internet to access, not just to those with my public key like in iroh. It's limited to 3 ports. It requires setup for each device. It's not peer-to-peer. It has throttled bandwidth.

No, this does not do the same thing as iroh. Not even close.

Dynamic DNS takes setup for every single device, and obviously doesn't work for devices that switch networks frequently. It also doesn't help you if the IP is behind a NAT.

We built & continually check that iroh can compile to WASM & run in the browser

DNS doesn't work with constantly changing IPs, like you have on mobile networks. DNS also doesn't help when the IP is behind a NAT. So I really don't see how the two are similar at all.

Everyone I'd like to connect to isn't on my tailscale, nor do I want them to be.

Your phone and laptop don't have stable IPs, let alone DNS entries pointing to them.

From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.

Not an expert but this is how I understand it. Yggdrasil is a P2P mesh network. You configure peers to join the network and your computer becomes a relay node for everyone else to use. It doesn't work behind a NAT without port forwarding.

Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.

Run gitlab or gitea.

BG3 is actually a perfect counterexample here. It doesn't have DRM, doesn't require an online account to play and uses direct connections for multiplayer. Nothing needs to be done to preserve it.

The way to manufacture more efficient compute now is do things like put DRAM closer to the chip and even closer integration between CPU and GPU. The fact that Apple can co-design their silicon such that the CPU and GPU can pull from the same pooled RAM is a major advantage over competitors.

When you have CPU, GPU, and even DRAM sitting on the same "die

Apple has been really successful convincing people they've done something special here. Given how many people are so horribly misinformed about this I'd go so far as to call it false advertising.

No, the DRAM is not on the same die. It's on package. They're literally standard SK Hynix memory chips.

Yes technically there's a latency advantage, but comparing M1 to DDR5 desktop chips Apple actually has worse overall memory latency.

Every integrated graphics chip from Intel and AMD has had unified memory for the last 10+ years.

Compute itself is also not what makes the Apple chips get long battery life. Looking at tests under full load the M1 is significantly worse than the latest Intel or AMD, yet it still gets better battery life under normal usage. The efficiency does not come from compute but from a whole host of idle consumption optimisations Apple brought over from their phone chips.

If the returned value is still valid despite an error, then the function would return (u32, Option<Error>), perfectly valid rust. If the value is meaningless in case of an error then using it is incorrect code; you wouldn't want to do that in either language and rust makes that assumption explicit with unwrap. If you want a default value in case of error just use unwrap_or_default.

Significantly less so than before, but it's unfortunately still the case. It's also just now getting features that people have been asking for for over a decade, and of course due to the nature of Wayland the implementations of these features are sporadic and inconsistent.

There's a big difference between authoritative networking with some security holes and non-authoritative networking. Note also that hitting 100% headshots is entirely within the rules of the game; it has nothing to do with the networking implementation.

Apple is no stranger to using a web browser for basic OS functionality. Several pages in the settings app are actually WebKit, source: https://blog.jim-nielsen.com/2022/inspecting-web-views-in-ma...

All these games already have an authoritative server. These cheaters aren't breaking the rules of the game by being invincible, super speedy, etc. they're aim-botting and wall hacking. Those cheats can't be prevented with authoritative networking.

And yet there's plenty of competitive multiplayer shooters that work fine on Linux. Rivals, The Finals, deadlock, CS2, Overwatch, Hunt Showdown, etc.

EA did a big announcement about switching to kernel level Anti-Cheat for Battlefield 6 to combat cheating, yet there's still plenty of cheaters around. It's looking more and more like an excuse in order to give the appearance of combating cheating.

Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases.

Some corrections:

Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break backwards compatibility.

Python saw 5 major releases, each breaking backwards compatibility. Counting all releases they had 132.

Node has an LTS every year. There were 6 LTS versions in the last 6 years. Those releases also included major breaking changes.

Go had no new major version, like rust it's only made minor changes.

So going by the author's own evaluation, rust and go are considerably better for project decay.

For example, I just looked at the dependencies of a small project I'm working on, and we have 5+ (!) different crypto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto

ring is explicitly an experiment, not suitable for use. My guess is the author looked at their Cargo.lock to determine what duplicated dependencies they have.

For the uninitiated, rust libraries can have optional dependencies that only get included under certain conditions. A common pattern is for a library to support multiple underlying implementations, such as different crypto libraries. For instance rustls has both ring and aws-lc-rs as optional dependencies, meaning that both get included in the Cargo.lock file when resolving dependencies. That doesn't mean that both are actually being used.

Note that at least for now you can also downgrade the firmware and use the "legacy" plugin with OrcaSlicer to fully restore functionality.