On 02/13/2013 10:25 AM, Pekka Paalanen wrote:
On Tue, 12 Feb 2013 18:37:50 +0000
Rob Bradford <[email protected]> wrote:
On 12 February 2013 15:52, Ander Conselvan de Oliveira
<[email protected]> wrote:
Input device initialization takes several microseconds to complete. Two
milliseconds, I assume :-)
things causes this: compiling the XKB keymap and reading the properties
database from the udev daemon. The user can't really interact with
anything on the screen until something is displayed, so this can be
delayed.
On my system, this patch saves ~50ms from launching Weston to have the
first frame displayed.
Hey Ander, I like the idea of this :-) However can I raise the concern
that although you're going to be starting weston fast - and getting to
that first frame fast!. Won't we then miss the opportunity to do the
next 3 frames on the vblank - since we'll be be blocked doing the
device setup.
My thoughts exactly. Furthermore, since Weston usually starts with the
fade-in animation, the first frame will be 100% black. I assume the
fade-in animation starts at that point, and then we will have a big
jump when the next frame of the animation gets drawn. Is the speed-up
even visible to a user?
I like the idea, though.
That is a concern I had. It turns out that for this modification alone
this is not noticeable. Our first frame is black anyway. I changed
Weston to not have the fade animation and made sure the first frame was
rendered only when the shell sets the background and I still could not
notice anything. I can't move my right hand from the keyboard to the
mouse that fast. ;)
But it seems that a more robust solution is needed. I hope there is more
stuff that can be done after we are already rendering. On my ideal setup
the shell would launch fast enough and be able to display something (a
splash screen at least) while we finish the setup for the rest.
Cheers,
Ander
Can we be clever about this and split the device setup into some
separate blocks of idle code so that we never block for that solid
period? e.g. xkbcommon compilation (could we even cache this compiled
data?) in one idle, udev interaction in another.
Seems possible for the udev part. It seems to take 2ms for each input
device, so we could try to split that. I'm not sure how we would make
the event loop give some priority to the page flip events though. Just
adding a bunch of idle task doesn't seem to cut it.
Might be hard. Especially if you wanted keymap compilation to not stall
the compositor, it would need to be threaded, I believe.
It seems it takes more than the time of a frame to compile the keymap,
so we would either have to do it in a thread or cache it.
What I have actually seen as a user is, that the initial fade-in
animation appears to start in the middle; it's not always a fade-in
from 100% black, the desktop may just appear in an instant, perhaps due
to skipping the beginning of the fade-in animation.
The fade animation starts from the call weston_compositor_wake() just
before we start the main loop. So it could happen that the shell sets
the background only after the fade is already in the middle. Perhaps we
should have something else trigger the wake.
Cheers,
Ander
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
