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