Benchmark of Wayland

[Justin Lee]

2010/11/18 jonsmirl at gmail.com <jonsmirl at gmail.com>:
>>> 2010/11/18 Justin Lee <justinlee5455 at gmail.com>
>> I pointed out the latency because I don't want to see any lag when I
>> scroll down a web page in my browser. I have noticed that in X when I
>> dragged down the scroll bar in browser, the scroll bar wasn't tied to
>> the mouse pointer and the scroll bar fell behind the mouse pointer.
>> When the scroll bar was dragged down, the web page wasn't updated
>> immediately. Instead, the page got updated until a small period of
>> time was passed after the drag happened.
>
> You won't see stuff like that in Wayland. In Wayland the apps paint
> their windows and then tell Wayland to display the complete picture.
> If an app updates the scroll bar, tells Wayland to draw, updates the
> window, tells Wayland to draw. Then you'll get what you describe. But
> it is the app that is broken, not Wayland. Get rid of the extra draw
> command in the app. Wayland is just doing what you told it to do.

Good point, that's the real solution/usage to make mouse pointer,
scroll bar and window update all tied together. I didn't come up with
that.

However, the latency issue will unlikely be solved! I mean when you
start the drag down, you won't see any change on you screen. The
change on you screen should occur at least until the scheduler hands
on CPU resource to Wayland server process. So there are still interval
in between and causes delay, but it appears in a more synchronized way
(pointer, scroll bar, window update will all changed at once, not one
after another).

> It is also pointless to update your video buffer faster than the scan
> rate of the video monitor. If you are generating 400fps, how do you
> display it on a 60fps monitor? Maybe update in the middle of a scan
> out, but that's probably going to tear the display.

Yup, but I don't think we can easily make scheduler context switch
synchronize with the video buffer scan, which means sometimes client
update will miss the video buffer scan.

For example, suppose that a client sends out a GEM buffer to Wayland
server just 0.001 msec. ahead of the next video buffer scan, there is
a big chance that the scheduler is not faster enough to switch to
Wayland process in such a short period of time. So the GEM buffer sent
by the client need to wait until the next-next video buffer scan such
that the buffer gets composited and shown. If there are too many
processes wait to be scheduled in the system, the GEM buffer will need
to wait even more time, maybe until the next-next-next... video buffer
scan to get composited and shown!

If the scan rate is at 60Hz, the scan period is 16.7ms (1/60). So the
latency will >= 16.7ms for the next-next video buffer scan, >= 33.3ms
(2*16.7) for the next-next-next video buffer scan ... and so on. If
the scan rate is half of 60Hz (i.e. 30Hz), the latency will be
doubled.