Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> At some other point after the client has marked its window as being updated, meaning that you have around two frames of latency (first frame is your input being sent to the application while the application is drawing itself, meaning that the input will be processed later so the response to your input is a frame late and second frame is the application notifying the window server that the window is outdated while the window server is drawing the output, meaning that the new contents will be used in the next frame).

Not every action takes an entire frame. The timeline can easily be like this:

  0ms: old frame starts to output
  4ms: input happens, application wakes up
  9ms: application finishes rendering
  15ms: compositing happens
  16ms: new frame starts to output
There's nothing about compositing that requires it to add any significant lag on top of rendering time plus transmit time. If input shows up while you're already drawing? That could happen without compositing. Just draw again or do whatever you'd do without compositing.

> Yes, wasting resources with every application having to maintain their own buffer for each window's contents even though those contents will not change for the vast majority of the window's lifetime for most windows is crappy.

Why waste time redrawing it if it's not changing? And a full-screen window on 1080p is only using 6MB for that buffer. Compared to the processes I'm running, the frame buffers are quite lightweight.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: