|
|
Log in / Subscribe / Register

BFS vs. mainline scheduler benchmarks and measurements

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 14:41 UTC (Mon) by cortana (subscriber, #24596)
In reply to: BFS vs. mainline scheduler benchmarks and measurements by ldarby
Parent article: BFS vs. mainline scheduler benchmarks and measurements

FYI, the reason Flash is so godawfully crap at playing video is because it actually *does* have to do a lot more than mplayer.

All mplayer has to do is decode video to YUV and then hand the picture off to the video card, which scales it to fit the screen, etc, in hardware.

Flash has to decode the video, then convert it to RGB, then combine it with other graphical elements created on the fly by a flash movie written by someone who has no idea how to program efficiently, then somehow get the result to the screen, and the methods for doing this for RGB data on Linux are buggy, inefficient, and hardware-dependent (when they even exist in the first place!)

Having said that, there is a great deal of room for improvement on the Flash side as well. One of the people who works for Adobe in porting the Flash player to Linux--a thankless task!--occasionally posts to a blog where he details interesting problems he runs into. Some interesting posts include:

http://blogs.adobe.com/penguin.swf/2008/05/
http://blogs.adobe.com/penguin.swf/2006/10/
http://blogs.adobe.com/penguin.swf/2006/09/#a001737

and another that I can't find right now where he writes about how the Windows version is accelerated by assembly code which has been optimised for years, but the Linux version can't because it's all locked away in Microsoft's assembler source format or something.


to post comments

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 15:30 UTC (Mon) by Cato (guest, #7643) [Link] (1 responses)

That point about the Microsoft assembler format is curious - surely it wouldn't be that hard to translate that format to GNU's? A small investment of time and a massive return if Adobe were to then use accelerated assembly code for Flash...

BFS vs. mainline scheduler benchmarks and measurements

Posted Sep 7, 2009 16:38 UTC (Mon) by cortana (subscriber, #24596) [Link]

Found it!

http://www.kaourantin.net/2005/08/porting-flash-player-to...

Now, the 'see this post for updated info' does say that this information is outdated, and that version 9 of the Flash Player on Linux is much faster than previous versions (which it was).

I still think there's huge room for improvement. But I understand that, while the Windows Flash Player developers spend time on optimizing, the Linux porters have to spend time making it work on a much wider variety of environments and with different versions of different libraries and graphics drivers and dealing with bugs in all of the above that are fixed in newer versions that end-users can't install because their distribution hasn't been updated for over a year, etc. etc.

For instance, I Flash won't bother to use the GPU on my Intel based laptop to accelerate rendering because:

$ glxinfo | grep 'client glx vendor'
client glx vendor string: SGI

and 'SGI' implies 'software rendering', which of course isn't true on my Intel-equipped laptop, but apparently when the developers tried to use a better method it would cause crashes on some distributions...

Details at <http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the...>.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds