6 ms·
> I'm not sure even operating systems do Oddly enough Windows used to be a lot better at what you describe than it is (in practice) today. I've used old system
by EscapeFromNY 3y ago
> I'm not sure even operating systems do
Oddly enough Windows used to be a lot better at what you describe than it is (in practice) today. I've used old systems where it took 0.5sec to clear the screen, and you could see the color sweep down the monitor from top to bottom. Now THAT is slow. Because of that the OS used a lot of tricks to minimize drawing, such as xoring the caret, and precisely tracking dirty regions to minimize the number of pixels drawn, etc.
Much of that finesse has been lost in this new generation of GUIs built on 3D APIs where the entire window is thrown away and redrawn every frame.
- pjmlp 3y agoWhich is why on modern Windows one would use the compositor APIs as well, however that implies some COM fun, which could be great if WinDev wasn't stuck in their ways on how to provide tooling for it.
- audidude 3y ago> Much of that finesse has been lost in this new generation of GUIs built on 3D APIs where the entire window is thrown away and redrawn every frame. GTK 4 uses eglSwapBuffersWithDamage() scissor clipped to the union of the damage rectangles. Operations falling outside that clip are culled. Only the damage areas are composited, assuming a competent compositor.
- andrewmcwatters 3y agoI think you're right. It used to be practice to limit your invalidation rect/region based on known bound information. Now every developer treats their entire buffer as a cheap throwaway and they couldn't be further from the truth.
- mike_hearn 3y agoIt's still done. JavaFX does dirty region tracking for example, e.g. here https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/es2/ES2SwapChain.java#L55 https://github.com/openjdk/jfx/blob/master/modules/javafx.gr... and that's a toolkit that's still relatively modern (it was ahead of its time). For example the UI thread is separated from the rendering thread, so one core can be computing the layout/processing events/doing animations for one frame whilst another core renders another frame to a GL/D3D command stream.