Benchmark of Wayland

[jonsmirl at gmail.com]

On Wed, Nov 17, 2010 at 9:56 PM, Justin Lee <justinlee5455 at gmail.com> wrote:
> 2010/11/18 microcai <microcai at fedoraproject.org>:
>>
>>
>> 2010/11/18 Justin Lee <justinlee5455 at gmail.com>
>>>
>>> This kind of latency due to OS scheduling could be eliminated by
>>> direct-procedure call. That is, the client passes the GEM buffer to
>>> the server just like it passes the GEM buffer as an argument to a
>>> function. In this approach, the compositor is not a process. Rather,
>>> the compositor is just a function live in the client program. So there
>>> will be no context switches.
>>
>> So ? Move wayland entirely into the kernel ? Then there will be no delay.
>
> No, I don't think so. The necessary infrastructure have been there in
> the kernel (i.e. DRM, GEM, KMS). I don't think we should bother
> writing kernel code which is error-prone and need specific care to
> avoid bugs and instability. Besides, I don't think moving Wayland into
> the kernel will be any beneficial if we could do all the same thing in
> user space.
>
> 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.

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.

I believe the current design of the system is correct in regards to
the kernel. The interesting path is moving more things (like glyph
generation) onto the GPU.

>
> This kind of issue would be solved in direct-procedure call approach,
> because  function call is synchronized. The function get executed
> right away after the caller calls it. It is the most *direct* manner I
> can think of.
>
>> And that's probably what MacOSX and Windows NT does. As far as I know,
>> Darwin uses quantz (AGL?)  as basis of their GUI system , but WIndows NT
>> uses bullshit GDI .....
>
> <<<bullsh*t>>> GDI?????
> Sounds like you are radical Microsoft hater. Yeah, many Linux users
> hate MS, but there is no need to be so radical in a mailing list which
> is unrelated to MS. ...I mean there are many MS forums on the net, you
> know.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Jon Smirl
jonsmirl at gmail.com