Flex2 Beta3 disappointments

I cannot couch my disappointment about the current beta3 related to the BitmapData.setPixel method.
A simple test confirms, that the setPixels method is now 30% slower than before. After that test, I converted my 3dengine (beta2) to the current beta3 and the framerate drops from 76 to 55FPS. So, simply put, I will abort the research about-perspective texture-mapping in AS3.

I know, there are many wonderfull things to do with AS3, but hey, it was is still a dream…

30 thoughts on “Flex2 Beta3 disappointments”

  1. You seem pretty disheartened with AS3 lately, and I can see why. Flash is always a disappointment because they never give us what we ask for every single time a new player is being made – speed. Yes they do improve things, but only in relatively small increments – for example we got all the lovely filters in Flash 8, but the speed of the player isn’t actually good enough to use them for the cool stuff we’d like to. The simple example is 3D z-based focus/blurring – yes it is possible, but it really knackers player speed to the point where not much else can be done as well.

    I hope don’t give up on perspective texture mapping in AS3, or at least give up for a while and come back later – you never know, speed may increase again in the next beta, it may have been a simple oversight or something that reduced it.

    Maybe you should ask for a job with the adobe flash development team, I reckon you could drive some pretty cool advancements :)

  2. One thing to keep in mind is that right now there is only a debug version of the player available. The debug player includes all sorts of hooks for debugging code, stepping through lines of actionscript, call stack logs, etc. All of this “extra stuff” slows down your code.

    When the official release player is available, I would expect that you’ll see much better performance just as a result of all of the debugging code being removed. Don’t give up hope just yet!

  3. “When the official release player is available, I would expect that you’ll see much better performance”

    I would like to trust your thoughts. Why we have the opportunity to start a Run- or Debugplayer ? The Runplayer is by now much faster than the Debugplayer. My readings rely on the Runplayer.

    So are you talking about the next ‘magic’ Runplayer generation, where we have no access right now ?

  4. Better that you bring it to their attention now so that they can undo whatever they did to slow down setPixel for the final release ;)

    Don’t give up before the race has begun!

  5. “Better that you bring it to their attention now so that they can undo whatever they did to slow down setPixel for the final release”

    So then: POST IT !!! :)
    We need to be heared and it must be clear, that this is a very important thing. It complicates any kind of image processing.

  6. Darron has the right idea…the debug player that ships with Flex Builder is much slower than the release player. If you want to try out a release player, you can get it here…

    http://www.adobe.com/products/flashplayer/public_beta/

    If you use one browser for FlexBuilder testing, use another browser for testing the release player.

    In my tests, on a 2.8 GHz P4 desktop machine, I can do approximately 44 Million setPixel calls a second in the release player. In the debug player that comes with FB, I can do less than half this amount.

    Werner Sharp
    Flash Player Engineering

  7. I get a huge performance increase from 24fps with the so-called “debug player” using FireFox to 24fps using the powerful release player under IE.

    So we calculate the distance |24 – 24| which seems to be 0?

  8. The difference in speed between the two players is very dependent on what your SWF is doing. An animation heavy SWF will show no change in performance. An AS3 heavy SWF like Andre is testing (or my setPixel test) should show significant improvement. The overhead in the debug player is related to keeping debug state of running AS3 code for things like function calls, etc.

  9. Hi André! :-)

    My money would have been on “fill the pixels in memory then set them all at once”. But since this yields the same speed there is either a very serious issue or Macromedia simply didn’t bother to optimize.

    By the way, setPixel is slow in Director as well. Here you HAVE to do everything in an off-screen buffer prior to drawing.

    Cheers, Holger.

  10. Hi Werner, thx for the comments. Could you give some more detailed information. What is happening if a function is able to throw for example. Is everything getting a little bit slower?

    I am also using a lot of getPixel methods.

    Here is my current result after some optimizations:
    http://je2050.de/showroom.php?file=Main

    I get about 26fps now with the new player.

  11. I know there r many wonderful things to do with AS3 and one should keep on trying. Right said Andre don’t give up before the race has begun. I m still trying it.

  12. You seem to be little disappointed with use of AS3 and i know flash is always a problem. It never gives us what we want. But one should never lose hope!

  13. One should keep on try using it. Someday u might be able to use it properly and make full use of AS3.
    All the best!!!!!!

  14. I hope don’t give up on perspective texture mapping in AS3, or at least give up for a while and come back later – you never know, speed may increase again in the next beta, it may have been a simple oversight or something that reduced it.

  15. You seem to be little disappointed with use of AS3 and i know flash is always a problem. It never gives us what we want. But one should never lose hope!

  16. Fantastic blog.One thing to keep in mind is that right now there is only a debug version of the player available. The debug player includes all sorts of hooks for debugging code, stepping through lines of actionscript, call stack logs, etc. All of this “extra stuff” slows down your code.thanks for sharing valuable article..i really like it.keep up with work..

Comments are closed.