From: Brad Fitzpatrick (brad@danga.com)
Date: Fri Nov 30 2001 - 18:34:56 PST
Perhaps the plugin threads shouldn't access the evas directly, but rather submit things to the queue as they did before. Then another thread does the same algorithm you did before.
The real point of using threads was to make plugins more straight-forward to write. In other words, being able to do: for (i=0; i<j; i++) { usleep(n); pretty_thing(i); }
----- Original Message -----
From: "Evan Martin" <martine@cs.washington.edu>
To: <further-devel@sourceforge.net>
Cc: "Brad Fitzpatrick" <bradfitz@bradfitz.com>
Sent: Friday, November 30, 2001 6:28 PM
Subject: [Further-devel] further and threads
> (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
>
>
_______________________________________________
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