A different way to handle pulse timing

[Artem Ananiev]

On 8/5/2013 10:26 PM, Richard Bair wrote:
>>>> In the past we have seen situations where there are so many
>>>> tasks on the user event thread, that user response (even on
>>>> desktop) was not acceptable. Some of these items are getting
>>>> better as we improve design (ie less redundant layout
>>>> operations causes by a single change/event).
>>> Right, but I don't see how that could still happen in this
>>> proposal? The problem before was the pulse events were handled
>>> outside of the event queue (as I recall) so that they got higher
>>> priority. We got rid of the higher priority and starvation
>>> ceased. This proposal would not reintroduce priorities, so I
>>> don't see how you could end up with input event starvation
>>> again?
>> rendering is "staged" on the event queue (layout, adding the render
>> job to the render thread). It has been this way for quite a while
>> now. As far as I remember,( other than paths with "live resize"),
>> we have never had a mechanism that provided for event priority (at
>> least not on the Linux side where I tend to live).
>
> This is how I thought it used to be done: we had (still have) a
> separate glass thread which fires off once ever 16ms or so. We used
> to take this pulse and handle it at the next available opportunity,
> which was explicit prioritization. If the pulse handling took longer
> than 16ms, by the time the pulse ended we'd have another pulse ready
> to be handled and would starve the queue. Today, we get this event
> and add it to the event queue, so we are never starving the event
> queue.
>
> In this proposal, we also would be putting the next pulse on the end
> of the queue, so it is impossible to starve input events.

Putting the next pulse on the end of the queue is surprisingly difficult 
task, at least on Windows. If we use standard APIs provided by the 
platform, PostMessage() and SendMessage(), events are always put to the 
head of the queue. If we use timer events, they are of the lowest 
priority, so we'll have "paint starvation" instead of "input events 
starvation".

Thanks,

Artem

> Thanks
> Richard