Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Desktop compositing latency is real

lofibucket.com

Post reply on HN
Print view View original

291–300 of 306 posts

Re: Desktop compositing latency is real

#291

Post by em3rgent0rdr »

Retric wrote: post #290
astrodust wrote: post #190

Earlier quoted context omitted.

It's a terrible idea. USB-3 is faster than 1Gbit/s. and there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing. Ethernet isn't optimized around short-haul signals, like computer to screen over a few metres at most, it's for 100m+ runs in datacentres. The signals have to be a lot more durable.

5120 * 2880 * 32bits * 60FPS is only 28.3 Gbit and both 40Gbit and 100Gbit are well established standards. Granted 40GB cards are running 50$ and 100Gbit cards are running ~700$, but that's most from the low volumes involved. Really though the larger issue is Ethernet connectors are not designed to be plugged in and removed regularly.

> "Ethernet connectors are not designed to be plugged in and removed regularly"

Well could easily use a smaller and easier plug while still being pin compatible with ethernet.

Re: Desktop compositing latency is real

#292

Post by Sephr »

Jasper_ wrote: post #116
83457 wrote: post #33

Earlier quoted context omitted.

"I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?" - John Carmack

Right, the issue is that 60Hz is ridiculously slow. Ethernet hardware is multiple orders of magnitude faster. It's just because of broadcast TV and CRT legacy. G-Sync / FreeSync allow up to 240Hz, which is ~4ms latency.

G-Sync and FreeSync have nothing to do with the available maximum refresh rate on any monitor. That is a property of the display interface.

Re: Desktop compositing latency is real

#293

Post by badsectoracula »

nhaehnle wrote: post #270
badsectoracula wrote: post #264

Earlier quoted context omitted.

There is a very good practical reason why the compositor is in no position to fix that even if it could theoretically be possible. A major source for the compositor latency (or actually, the increased response time you get with a compositor) is that the "render to back buffer" (ie. compositor's texture, at the best case) and the "blit to the front buffer" (which happens by the compositor by drawing the window geometr…

This "do not happen at the same time" is true in plain Xorg as well, though, since the final blit to the screen happens in the X server and not in the application. Your example of 100fps vs. 130fps on the same screen is inherently unsolvable in a proper way with anything less than a 1300fps display. So you have a bunch of tradeoffs, and I'm sorry to say that if the tradeoff you prefer is tearing, you're in the losing…

Without a compositor, when you ask to draw a line, a rectangle, a circle or even a bitmap, it is drawn immediately. Sure, it isn't done in zero time, there is some latency, but that is the case with any graphics system :-).

As for the compositor, it isn't impossible to create a Wayland "compositor" that draws directly on the front buffer either, it is just harder and pointless since Xorg exists :-P.

But yeah, if everyone abandons Xorg (and by everyone i mean Everyone, not just the popular kids) and nobody forks it (which i doubt it'll happen as there are a ton of people who dislike Wayland) and nobody else steps up to do something about it, then yeah, i'll most likely just make my own suckless Wayland compositor. I'd prefer the world to stay sane though so i can continue doing other stuff :-P.

Re: Desktop compositing latency is real

#294

Post by brokenmachine »

thesmok wrote: post #272
mark-r wrote: post #178

Earlier quoted context omitted.

I don't understand why someone hasn't come out with a dedicated keyboard chip yet. If it's cheap enough you don't need to run all the keys to a single chip, you could have multiple chips that all talk over a serial bus to one that it designated the master.

Another layer of serial interfaces would make it even slower.

A serial interface can run a lot faster than anyone can type, eg i2c high speed is max 3.2Mbit/s.

SPI can be way faster than that I believe.

Re: Desktop compositing latency is real

#295

Post by snvzz »

raphlinus wrote: post #98

I'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…

>attach animations so the motion is silky smooth

Yeah, because there isn't enough latency already.

Hell no.

Re: Desktop compositing latency is real

#296

Post by thesmok »

brokenmachine wrote: post #294
thesmok wrote: post #272

Earlier quoted context omitted.

Another layer of serial interfaces would make it even slower.

A serial interface can run a lot faster than anyone can type, eg i2c high speed is max 3.2Mbit/s. SPI can be way faster than that I believe.

true, but adding another link (microcontroller) in the chain is going to add delay anyway. I think the original suggestion was pointless: instead of adding more microcontrollers you can just replace the main uC with the one that has enough pins. The reason this is not done is uCs with >100 pins are usually more powerful and expensive, so you can't just pay for more pins -- you also have to pay for more processing power and features you don't need.

Re: Desktop compositing latency is real

#297

Post by crzwdjk »

raphlinus wrote: post #125
pjc50 wrote: post #121

Earlier 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…

Typically hardware will have the base layer, a cursor layer, and possibly a video overlay. But in many cases, the video "overlay" is actually emulated by the driver using a shader to do the colorspace conversion and the texture hardware to do scaling.

Re: Desktop compositing latency is real

#298

Post by lightedman »

em3rgent0rdr wrote: post #233
astrodust wrote: post #190

Earlier quoted context omitted.

It's a terrible idea. USB-3 is faster than 1Gbit/s. and there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing. Ethernet isn't optimized around short-haul signals, like computer to screen over a few metres at most, it's for 100m+ runs in datacentres. The signals have to be a lot more durable.

> "USB-3 is faster than 1Gbit/s" But Cat 6 Ethernet is 10 Gbit/s.

You can do more than that if the run is rather short. Cat6 is used on the 20Gbit cross-links on many stackable rack-mounted switches.

Re: Desktop compositing latency is real

#299

Post by CyberDildonics »

Retric wrote: post #289
CyberDildonics wrote: post #171

Earlier quoted context omitted.

No, the issue was that he was using a display with a crazy amount of buffering because they were doing so much filtering and doing it poorly.

It's not just monitors even keyboards can have 40+ms worth of delay and it all adds up.

I don't think that was what he was referring to

Re: Desktop compositing latency is real

#300

Post by CyberDildonics »

pcwalton wrote: post #288
CyberDildonics wrote: post #282

Earlier quoted context omitted.

That seems like a dubious claim to me. In my experience maxing out memory or pcie bandwidth is rarely a bottleneck, and extremely unlikely / impossible with low CPU usage. Do you have a link or more detail about 'already cramped pipelines'?

2D rendering on GPUs is almost entirely memory bound. Source: I've been working on GPU 2D rendering full time for years now.

You seem to be implying that rendering of a text editor has to be all 2d and that rendering a frame pushes the memory bandwidth to it's limits, both of which can't possibly be true. Why can games run at 144hz and above but a text editor can't afford to overdraw for decreased latency?
Post reply on HN