Desktop compositing latency is real • Hacker News Board

Re: Desktop compositing latency is real

#51

Post by nwah1 » Tue, Nov 21, 2017, 2:56 PM UTC

srcmap wrote: post #35

According to this: https://www.youtube.com/watch?v=BTURkjYJ_uk Firefox's servo engine can compose CSS elements/Display List together at 500 frames / second. Maybe next version of Windows / Linux desktop should use FF's servo engine?

Depends on the complexity of the html and CSS in question. To reproduce a full desktop environment, even just using Canvas, would be challenging and I highly doubt it would allow 500fps.

Re: Desktop compositing latency is real

#52

Post by solotronics » Tue, Nov 21, 2017, 2:57 PM UTC

em3rgent0rdr wrote: post #48

pjc50 wrote: post #41

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

ethernet over multimode fiber, I want to be able to have accessories hundreds of meters away from my computer

Re: Desktop compositing latency is real

#53

Post by bufferoverflow » Tue, Nov 21, 2017, 2:57 PM UTC

srcmap wrote: post #35

According to this: https://www.youtube.com/watch?v=BTURkjYJ_uk Firefox's servo engine can compose CSS elements/Display List together at 500 frames / second. Maybe next version of Windows / Linux desktop should use FF's servo engine?

Don't confuse bandwidth and latency.

Re: Desktop compositing latency is real

#54

Post by amiga-workbench » Tue, Nov 21, 2017, 2:57 PM UTC

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?

Try popping the start menu open on a Windows 10 machine with a mechanical hard drive.

Re: Desktop compositing latency is real

#55

Post by teekert » Tue, Nov 21, 2017, 2:59 PM UTC

pmoriarty wrote: post #22

This article is about Windows, but I wonder how Wayland on Linux measures up.

Me too, since devs like those of libinput are specifically and actively addressing such latencies.

Re: Desktop compositing latency is real

#56

Post by wruza » Tue, Nov 21, 2017, 3:01 PM UTC

fredley wrote: post #37

Zardoz84 wrote: post #31

> Don’t you find it a bit funny that Windows 95 is actually snappier than Windows 10? It’s really a shame that response times in modern computers are visibly worse than those in twenty years ago. My Amiga A1200 (Only have extra RAM) feels faster and more responsive that any modern computer with Windows or GNU/Linux desktop.

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 must be something very wrong with traditional ui systems?

Edit: my apologies, I didn’t read the article first and thought it measured complete feedback like “press ctrl-f and wait for element to popup”, but I’m interested in my question regarding games anyway.

Re: Desktop compositing latency is real

#57

Post by raverbashing » Tue, Nov 21, 2017, 3:04 PM UTC

forgotmypw wrote: post #43

Someone recently gave me an old PowerBook G3, running Mac OS 8.6. I was amazed by how responsive the UI is compared to today's UIs, from Mac to Windows to iOS to Android. When I clicked something, it felt like there was a pushrod between the mouse button and the menu, which triggered it instantly.

Well compositing was introduced in 10.2, I'm not sure if running Classic Mac OS was an advantage in this case

Re: Desktop compositing latency is real

#58

Post by revanx_ » Tue, Nov 21, 2017, 3:04 PM UTC

The irony is that it's most often not the fault of the DWM for the latency but the applications themself. Since DWM acts as the screens double buffer, your application needs to be synchronous with the DWM frame timing, not being in sync means latency and flickering.

Re: Desktop compositing latency is real

#59

Post by bwat49 » Tue, Nov 21, 2017, 3:04 PM UTC

baybal2 wrote: post #36

The solution is simple - triple buffering

afaik dwm does use triple buffering

Re: Desktop compositing latency is real

#60

Post by yoz-y » Tue, Nov 21, 2017, 3:05 PM UTC

wslh wrote: post #2

Is this something related to the latest Windows 10 updates or it was always the case? I mentioned this because, may be unrelated, there are some slow drawings in the UI after the October major update. I can notice this when I login and the desktop is drawn.

The article mainly explores the difference with DWM (Desktop Window Manager) enabled and disabled. DWM's main role is to render all of the windows into separate buffers in memory and then "compose" them on the fly. This for example avoids the effect that dragging a window over a frozen application would result in glitches.

Since Windows 8 DWM can not be disabled. By default in W7 it is also enabled (the infamous Aero), but at least you can get rid of it.