[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: