From: Evan Martin (martine@cs.washington.edu)
Date: Fri Nov 30 2001 - 18:28:33 PST
(For the further-devel mailing list; I'm trying to redesign further to
use a separate thread for each plugin...)
So here's the problem:
Suppose that the fastest evas can update the screen is once every 10ms. (I
made this number up.)
Now say I have four processes currently animating, with a delay of
30ms between each "frame" of animation. If I start them all 5ms after
each other, then I have:
ms | event
---+-----------
0 | p0 starts
5 | p1 starts
10 | p2 starts
15 | p3 starts
30 | p0 fires - evas updated, so we block for 10ms on the update
35 | p1 tries to fire, p0 still has the lock, needs to wait until 40
40 | p2 tries to fire, p1 has just grabbed the lock, so p2 waits until 50
45 | p3 tries to fire, etc etc
As you can see, they're updating too rapidly together for the canvas to
keep up.
So the evas_render() call blocks, and then the threads get delayed
waiting for the mutex to free, and it looks like the whole system is
slowing down.
This problem is made even worse by handling X events; you need to update
the evas whenever an X event happens, so if you're currently animating
and you move the mouse across the screen (a fairly common operation!)
the animation slows noticeably.
...So what can I do? I'm beginning to think that the existing further
model isn't so bad.
Here's how the existing further handles it:
while further is running {
look at the top event on the queue
determine how long until this event should happen
select() on the X connection for that delay
if (the select times out) {
run the top event on the queue
*run every event on the queue that should've happened already
(this keeps lagging processes up)
} else {
handle the x event
}
update the evas
}
The bit marked with * is the critical bit to avoid visual slowness.
Because events are marked with absolute times (ie, I say "this event
should happen at time [x]") instead of relative ("delay for [x] ms"),
I can make processes effectively "catch up".
Any ideas?
!!!!
I might be able to do something with the main further process managing
the timing, blocking and waking up the threads when their times come,
then updating the evas in one big block. The more I think about this,
the more I think it might work...
--
Evan Martin
martine@cs.washington.edu
http://neugierig.org
_______________________________________________
Further-devel mailing list
Further-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/further-devel
This archive was generated by hypermail 2.1.4 : Tue May 28 2002 - 23:37:04 PDT