[PATCH weston 2/2] compositor-drm: Only add input devices after a frame is displayed

[Pekka Paalanen]

On Tue, 12 Feb 2013 18:37:50 +0000
Rob Bradford <robert.bradford at intel.com> wrote:

> On 12 February 2013 15:52, Ander Conselvan de Oliveira
> <ander.conselvan.de.oliveira at intel.com> 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.

> 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.

Might be hard. Especially if you wanted keymap compilation to not stall
the compositor, it would need to be threaded, I believe.

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.

Another possible cause of delays is that Weston itself does not draw
anything on start-up. It is the weston-desktop-shell, which needs to be
forked, initialised, get connected, load wallpapers, and render the
desktop elements, before Weston can show anything other than black.

Ander, does your use case differ from the standard Weston setup?


Thanks,
pq