[haiku-development] Re: trying to spark some re-interest in Window Compositing

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 11 Oct 2018 08:57:34 +0200

Hi,

Am 11.10.2018 um 05:34 schrieb looncraz:

Also, I fully anticipated a 1~3 frame lag.  Anything under approximately 100ms will be felt as nearly instant, particularly when multiple updates occur at the same time.

When you have a pen to draw directly to the screen, think Apple Pencil drawing onto an iPad, you want the lowest possible latency, since you will notice whether the line on the screen lags behind your pen tip, even if slightly. And it needs to be optimized across all subsystems as they work together, from input to screen update. I would absolutely aim for making this scenario work really well in Haiku as well. Apple even doubled the screen refresh rate from 60 to 120Hz, so the minimum technical latency is reduced even further from 17 to 8ms.

The driver can batch together draw calls from accelerants and issue them all at once - that's up to the driver author, not the app_server.  The app_server will provide full fall-backs.

My guess is that the entire app_server needs to provide completely different modes of operation. I don't think individual primitive drawing operations should be swapped out for a hardware accelerated one.

Full featured software-mode compositing is what I want to see - with a relatively easy path to implementing hardware acceleration in the future.

Yes, I guess there should be a new design which separates different responsibilities, divides them onto a number of threads with a certain locking model, and all of that should be designed with running on the GPU in mind, even if the first implementation is in software.

Best regards,
-Stephan

Other related posts: