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

171–180 of 306 posts

Re: Desktop compositing latency is real

#171

Post by CyberDildonics »

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.

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.

Re: Desktop compositing latency is real

#172

Post by beardbandit »

Flenser wrote: post #131
frik wrote: post #109

Earlier quoted context omitted.

If you are looking for such monitors, look for gaming monitors with TN-panel, with 2ms or 4ms response time. Compared to office monitors or even TVs there is a big difference. (mind that TN-panel have pro and cons)

What happens if you have multiple monitors? i.e. a TN-panel for gaming and an IPS for graphic design?

This is pretty much my setup. Higher quality TN panels don't have that much of a dropoff from median quality IPS panels.

Re: Desktop compositing latency is real

#173

Post by mastax »

jsd1982 wrote: post #124

> Virtual keypresses were sent with WinAPIs SendInput and pixels copied off screen with BitBlt. This methodology alone could account for the differences in timing between Win7 and Win10. For all we know, Win10 could just be slower at getting the pixels back to the program from BitBlt, or SendInput could be slower triggering events, or a multitude of other issues. The best way to truly detect key-to-photon latency is…

As I understand it:

- Compositing is done on the GPU

- BitBlt is done on the CPU

- Copies from GPU -> CPU are slow

So, yeah, compositing adds a frame of VSync latency, but these measurements are complete bunkum.

Re: Desktop compositing latency is real

#174

Post by ygra »

CyberDildonics wrote: post #165
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…

How are you testing the mouse cursor following the window borders on resize? I've read that windows turns off the hardware sprite mouse cursor when resizing windows so that it can software render it to always line up properly.

Oh. This explains why the cursor flickers briefly and gets drawn partially across multiple monitors when at the split instead of the normal mouse cursor which is drawn only on one monitor at a given time.

Re: Desktop compositing latency is real

#176

Post by TremendousJudge »

ssalazar wrote: post #157
wruza wrote: post #56

Earlier quoted context omitted.

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

Every realtime videogame, from AAA shooters built by hundreds of developers to tiny one man band indie platformers, is more responsive than the average desktop app. This happens because if the controls don't respond well, the game is automatically bad. Sadly this isn't the case with desktop apps

Re: Desktop compositing latency is real

#178

Post by mark-r »

falcolas wrote: post #126
madez wrote: post #100

Earlier quoted context omitted.

A keyboard doesn't need to implement a scanning matrix. It could hook up all keys individually to a an own IO-Port.

Requires a bigger chip (100+ IO pins) and more complex wiring diagrams than most inexpensive keyboard makers are willing to invest.

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.

Re: Desktop compositing latency is real

#179

Post by StillBored »

Cthulhu_ wrote: post #26
babuskov wrote: post #6

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? Comparing them on the same hardware?

There was a similar article a while ago comparing it to an Apple II, where Apple II was snappier on its own hardware compared to a modern computer.

I might be interested in seeing that if you can find the link.

I have a transwarped IIGS, which for CPU benchmarks is slower than most of the modern emulators, but on the actual hardware its pretty amazing (particularly since it boots faster from a compaq flash card than most win10 PC's i've seen). I would guess that a USB keyboard->windows->emulator->app response->draw->Emulator->windows->gpu path is much, much longer than the IIGS keyboard poll rate draw cycle even given the 1000 cycle/sec advantage a modern PC has.

Post reply on HN