If the delays are not nanoseconds but some significant quantity of milisseconds, those who do not want a gpu or do not have the option for one or for a driver would be harmed by it.
1 Like
The issue here is input latency, if I move my mouse how fast does the cursor move? In classic compositors this would add atleast one or severall frames of latency. If you take your display refresh rate, say 60hz you can devide 1000ms/s by it, to figure out how many miliseconds (not nanosecpnds) of input latency are added if you wait that frame
say (1000ms/s)/(60* 1/s) = 16,67ms
depending on how fast you move the mouse you will also travel some distance with it, you can the calculate with the m/ms (or if you want cm/ms or mm/ms)
how many cm or mm the thing you are dragging is behind the movement of the mouse.
In an ideal system the input latency would be less than a milisecond. We canât get there yet for various reasons, but on my hardware for example a <5ms response should be possible, if everything works together properly.
2 Likes
The mouse cursor isnât the best example as it lives in its own hardware plane and doesnât need to be composited, AFAIK.
Good example thank you
What would Be?
It is a perfect example for the problem of input latency, which is the main problem we care about. : )
(That or any object dragged by the mouse, we also have to take special care objects appear âgluedâ to the mouse, if objects move behind the mouse with delays this appears wobbly)
Thing is, at the end of the day, it doesnât matter whether it âlooks betterâ or not, the design of the Haiku Desktop makes it objectively better to use as a user. Maybe it does look dated, but thatâs just a matter of the theme, and it is what desktops should have become, instead of what they actually have become.
3 Likes
Underlying implementations of code looks good so I donât think there is need to compare it to 90âs, desktop is somehow semi-gorgeous (Is it bird is it plane?) and Haiku is prepared for all kinds of interesting stuff.
Some more thoughts about latency. First, it should be configurable: some people prefer absolute minimal latency, some people prefer no tearing and less power consumption. Some APIs such as Vulkan or Wayland can provide display preferences that can be respected by OS.
Second, even with no tearing, it is still possible to swap framebuffers faster than screen can refresh. But it mean that some frames will be thrown away without being displayed. This operation mode will have less latency compared to vsync mode, but it will waste computing resource.
5 Likes
If I recall correctly, Dano added double buffering to BeOS which made moving windows silky smooth and tear free.
3 Likes
You are worried for nothing, Iâm currently a mere beginer in c++, so no body is going to change any thing without concent (I believe code that is writen is first reviewed before being accepted and embeded into Haiku.)
You missed my point entirely.