3 ms·

A question for people who are more knowledgeable than me about Flash and Actionscript -- from whence do these performance problems originate? Is it primarily M

A question for people who are more knowledgeable than me about Flash and Actionscript -- from whence do these performance problems originate? Is it primarily Macromedia/Adobe's poor technology causing the problem, or is it developers writing really bad Flash applications? Or is it some other bad integration layer between Flash, the browser, and the hardware?

blasdel 17y ago
A) Macromedia + Adobe = :( B) Some flash video player wrappers are much worse than others. Hulu's is particularly slow, Comedy Central's basically refuses to work on Linux. C) Flash has to do the YUV->RGB conversion internally so that it can composite your poorly-conceived UI on top of it. It's almost immune to hardware acceleration (except in full-screen mode). Then it has to run in the main() thread of an intrinsically memory-gobbling application. D) All of the above
cjbos 17y ago
A bit of everything. Obviously the software vs hardware decoding of video is a major factor, but you'll also sometimes find ads/animation causing a huge CPU spike. This is almost solely due to a Flash Designer/Animator creating the flash movie, they tend to just bump the frame rate up to something ridiculous like 60-90 fps to get smooth animation, and also overuse onFrameEnter event handlers which can be attached using the timeline.
yason 17y ago
It isn't video decoding per se: the .flv videos are merely containers for real video encoding formats, and playback alone shouldn't eat considerably more cpu than with other players. Of course, if you have video decoding hardware you can even offload the heavy number crunching to that unit which kind of gives you "free" video except for any memory I/O overhead for video stream and buffering decoded frames. Flash runtime seems to be pretty slow, as for animating and as for executing ActionScript itself. I don't know how much AS3 helps in that, though. Compositing in Flash can be pretty heavy: SWF videoplayers often have a mix of layers for controls, progress bars, advertisements etc. that all have to be composited on top of each other. Even worse, the SWF videoplayer might be set to run at 40 FPS or 60 FPS eventhough the video itself runs only at 25 fps, for example. This means that Flash tries to render much more and more often than is needed for the video alone. This all happily cumulates: even if we can decode video frames fast enough, the frames still have to be synchronized through the choking Flash core and compositing which may be running late, causing delayed or dropped frames, jittering, unresponsiveness etc. If we played H.264 videos via HTML5 and JavaScript/CSS, I suspect that websites could (and would!) still program their videplayers to do too much and eventually choke on scripting and rendering. Similarly, I guess it's possible to create a lean&mean Flash videoplayer that just basically shows the video layer at the video FPS and nothing else. Disclaimer: I work on next-gen smartphones in a closely related field. YouTube chokes my EeePC 901 on Ubuntu; it runs much better on these little next-gen devices where practically anything graphics related is being accelerated.
GBKS 17y ago
There are any pitfalls in Flash development when it comes to performance and some of them are very difficult to keep in check. With the right knowledge and using a few tricks, Flash can be blazing fast. However, a lot of Flash developers do not come from a programming background, so it happens too often that they don't have the knowledge to master Flash. It takes a while to learn how to properly handle things like garbage collection and memory management (partly due to Adobe's documentation being sloppy as well). If all you do is "hit the bug" banner ads, it is unlikely that you have the time or the need to dive that deep.

blasdel 17y ago

A) Macromedia + Adobe = :( B) Some flash video player wrappers are much worse than others. Hulu's is particularly slow, Comedy Central's basically refuses to work on Linux. C) Flash has to do the YUV->RGB conversion internally so that it can composite your poorly-conceived UI on top of it. It's almost immune to hardware acceleration (except in full-screen mode). Then it has to run in the main() thread of an intrinsically memory-gobbling application. D) All of the above

cjbos 17y ago

A bit of everything. Obviously the software vs hardware decoding of video is a major factor, but you'll also sometimes find ads/animation causing a huge CPU spike. This is almost solely due to a Flash Designer/Animator creating the flash movie, they tend to just bump the frame rate up to something ridiculous like 60-90 fps to get smooth animation, and also overuse onFrameEnter event handlers which can be attached using the timeline.

yason 17y ago

It isn't video decoding per se: the .flv videos are merely containers for real video encoding formats, and playback alone shouldn't eat considerably more cpu than with other players. Of course, if you have video decoding hardware you can even offload the heavy number crunching to that unit which kind of gives you "free" video except for any memory I/O overhead for video stream and buffering decoded frames. Flash runtime seems to be pretty slow, as for animating and as for executing ActionScript itself. I don't know how much AS3 helps in that, though. Compositing in Flash can be pretty heavy: SWF videoplayers often have a mix of layers for controls, progress bars, advertisements etc. that all have to be composited on top of each other. Even worse, the SWF videoplayer might be set to run at 40 FPS or 60 FPS eventhough the video itself runs only at 25 fps, for example. This means that Flash tries to render much more and more often than is needed for the video alone. This all happily cumulates: even if we can decode video frames fast enough, the frames still have to be synchronized through the choking Flash core and compositing which may be running late, causing delayed or dropped frames, jittering, unresponsiveness etc. If we played H.264 videos via HTML5 and JavaScript/CSS, I suspect that websites could (and would!) still program their videplayers to do too much and eventually choke on scripting and rendering. Similarly, I guess it's possible to create a lean&mean Flash videoplayer that just basically shows the video layer at the video FPS and nothing else. Disclaimer: I work on next-gen smartphones in a closely related field. YouTube chokes my EeePC 901 on Ubuntu; it runs much better on these little next-gen devices where practically anything graphics related is being accelerated.

GBKS 17y ago

There are any pitfalls in Flash development when it comes to performance and some of them are very difficult to keep in check. With the right knowledge and using a few tricks, Flash can be blazing fast. However, a lot of Flash developers do not come from a programming background, so it happens too often that they don't have the knowledge to master Flash. It takes a while to learn how to properly handle things like garbage collection and memory management (partly due to Adobe's documentation being sloppy as well). If all you do is "hit the bug" banner ads, it is unlikely that you have the time or the need to dive that deep.