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

[Ander Conselvan de Oliveira]

On 02/13/2013 10:25 AM, Pekka Paalanen wrote:
> 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.

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