This patch seems to fix this problem in gnash:
=== modified file 'libmedia/MediaParser.cpp'
--- libmedia/MediaParser.cpp 2010-01-01 17:48:26 +0000
+++ libmedia/MediaParser.cpp 2010-08-06 02:34:19 +0000
@@ -411,7 +411,10 @@
while (!parserThreadKillRequested())
{
parseNextChunk();
- gnashSleep(100); // no rush....
+ {
+ boost::mutex::scoped_lock lock(_qMutex);
+ waitIfNeeded(lock);
+ }
}
}
Someone who knows what they're doing should check that I haven't done
something stupid. When I try it on Youtube, the media thread goes to
sleep anytime the playback is paused, or after the video is over; and
reawakens if you click to replay the video. But perhaps my scoped lock
won't really work in an inner scope, or something.
Oddly, gnash trunk only burns up one CPU core rather than two, with the
gnashSleep(100) in there. If I remove that, without adding the
waitIfNeeded, it burns up both my CPU cores while in the Youtube loop
after a video has finished playing.
However, even with this fix, gnash still burns a large amount of CPU
time, about one core's worth but somewhat variable, when it's doing
nothing after a YouTube video plays. Most of the system calls
involved are in the main thread. I'll keep looking at why.
John
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnash-dev
