jhfkuds
Desktop compositing latency is real
151–160 of 306 posts
Re: Desktop compositing latency is real
#152kjsdfksd
Re: Desktop compositing latency is real
#153Re: Desktop compositing latency is real
#154Kiel Fh
Re: Desktop compositing latency is real
#155Earlier quoted context omitted.
Why do people care about affiliate links? Serious question.
It's good to know that the person posting the link has a financial stake in it. Depending on the context this can mean a lot - like a review or recommendation.
Except it's Amazon. I could understand that position if it was a Dell affiliate link. But Amazon sells so many brands of monitors, any of which could carry the same affiliate code, that I don't see how that matters.
Re: Desktop compositing latency is real
#156Smartphones suffer from input latency too, though I’m unsure of the underlying cause (curious how iOS handles window/view drawing). It only seems to be getting worse, though I haven’t done tests on this. While each new model undoubtedly has better tech specs, the interface responsiveness doesn’t seem to improve.
Ghetto latency test: finger-scroll alternatingly up and down very quickly, see at which frequency your finger and scroll position are 180° out of phase, i.e. you finger is up while the contents are down or vice versa.
Smartphones seem to be fine according to that test. Android is very good and iOS is even better.
Re: Desktop compositing latency is real
#157Earlier quoted context omitted.
Layers of abstraction take you further away from the metal. The more layers of abstraction your keypress must traverse before rendering is complete and the photons have reached your retina, the longer it will be until that happens. Layers of abstraction make complex tasks more reachable by a larger number of programmers by reducing the amount of specialist knowledge about those lower layers required to do the job. Th…
Numerous games, including those having complex graphics and behavior, can render 120+ frames per second and realtime interactions (physics, optics, reactions) on pretty average hardware. I don’t think that game scripters who make final things like scenery or ui face complexity much harder than those in gtk/qt/wpf/htmljs widget programming. Details would be interesting though, since I’m no game developer. If true, it…
Cost/value.
AAA games with "complex graphics" take years to develop, cost millions of dollars to produce, require dozens of developers, are extremely power hungry, and require specialized GPU programming to make look good and render fast.
They are typically judged by how fast/smoothly they perform, so it makes sense to direct resources to this.
This isn't an approach most people want to take for average mobile or desktop GUI apps.
Re: Desktop compositing latency is real
#158Earlier quoted context omitted.
Solution: send the pixel to the screen over IP! (joking, but with a tiny serious element)
this reminds me of the argument that instead of going to USB C 3.1 as the grand unifying connector for all peripherals (including video), we should have instead migrated to Ethernet cables for everything.
Currently ethernet doesn't look cheap enough for video to me.
Even a simple 1920x1080 60Hz monitor needs 3 Gb/s, a 2560*1440 144Hz monitor 13 Gb/s, a 4k 60Hz 12 Gb/s.
DisplayPort 1.2 offers 17 Gb/s and DisplayPort 1.3 offers 26 Gb/s.
Re: Desktop compositing latency is real
#159I've been experimenting with this too, in the context of the Windows front-end for xi editor. It's absolutely true that the compositor adds a frame of latency, but I have a very different take than "turn it off." First, it's possible to design an app around the compositor. Instead of sending a frame to the system, send a tree of layers. When updating the content or scrolling, just send a small delta to that tree. Fur…
The issue with sending a tree of layers is that this prevents some important optimizations: avoiding overdraw with early Z becomes impossible, because your app doesn't know anything about the positions of the scrollable layers and so has to be conservative and paint all of their contents. So you trade a frame of latency for lots of overdraw, which is a tradeoff I'm not really comfortable making. (Note that today, almost all apps overdraw like crazy anyway, but that should be fixed.) :)
> Further, Microsoft engineers have said that hardware overlays are coming, in which the graphics card pulls content from the windows as it's sending the video out the port, rather than taking an extra frame time to paint the windows onto a composited surface.
This seems like the best solution to me. It allows apps to paint content intelligently to prevent overdraw while avoiding any latency.
Re: Desktop compositing latency is real
#160Earlier quoted context omitted.
> Instead of sending a frame to the system, send a tree of layers. Which API does one use to do this? I'm slightly surprised that hardware overlays aren't already a feature, especially given that they're handled by the graphics card. I know there's a special API for video overlay, especially DRM video (where part of the requirement is that the system doesn't allow it near the compositor where it could be screenshotte…
DirectComposition. It's been there since Windows 8, and is used by Chrome among other apps (see https://bugs.chromium.org/p/chromium/issues/detail?id=524838 ). It's possible some hardware already does overlays, given that the talk I linked above was 2 years ago. I haven't researched this carefully. There's a bunch of stuff in the interface to support video and also integrated 3D content ("create swapchain for composi…
> It's possible some hardware already does overlays, given that the talk I linked above was 2 years ago. I haven't researched this carefully.
All hardware does some overlays, though not a large number. (You can see Intel GPU overlay setup at [1].) One scanout overlay is already in use on all major OS's, to draw the mouse cursor.
[1]: https://github.com/torvalds/linux/blob/e60e1ee60630cafef5e43...