

Hacking SWF – Everything You Never Wanted To Know About Shapes In Flash - jgalvez
http://wahlers.com.br/claus/blog/hacking-swf-1-shapes-in-flash/

======
chipsy
My favorite of Flash's many non-sensical quirks:

If you create, in code, a Graphics object with a color of 0xFFFFFF(pure
white), it won't draw. But 0xFEFFFF will work. There is probably some setting
buried somewhere that impacts this, transparency/masking features being likely
culprits, but it certainly isn't documented in the APIs.

At times, it seems like everything in the Flash APIs suffers from some kind of
misfeature. You can load Sound data from a ByteArray, but not Video data. The
security policy mechanisms have changed in major ways at least three
times(maybe more, I've lost track) over the last three years, meaning everyone
doing Flash networked apps has to keep an eagle-eye on player updates. Because
Flash uses system fonts in lieu of including its own cross-platform default,
you can't count on text rendering the same across platforms unless you always
embed a font in your file(which, of course, adds file size). If you use alpha
transparency, it will render quickly on Windows, slowly on OS X, and molasses-
like on Linux, with the same hardware on all three. Accessing the stageWidth
and stageHeight properties on the first frame(e.g. in a statically instanced
variable) will give you an incorrect value. It just goes on and on like this.

But if you want to do something high-traffic and media-related on the web, you
don't have many alternatives - Flash has the appropriate features and the
largest deployment of any of the plugin-based options.

~~~
DarkShikari
_If you use alpha transparency, it will render quickly on Windows, slowly on
OS X, and molasses-like on Linux, with the same hardware on all three._

As good friends with the Linux Flash maintainer, I can say the primary problem
here is that Flash has to be extremely picky about the APIs it uses; even if
there's a very fast API that does what it wants, if that API results in
crashes due to bad drivers on 0.5% of machines (and Flash can't detect which
machines that 0.5% will be), Flash can't use it. This results in all kinds of
horrific platform-specific code and platform-specific results.

On a related note, the primary reason that Flash video playback is slower than
people expect is because it does forced software YUV->RGB conversion, as the
rendering pipeline does compositing in RGB, which is needed for (for example)
overlays on the video.

Speaking of which, if you want any specific feedback forwarded to said Linux
maintainer, I can do so ;)

~~~
moe
_if that API results in crashes due to bad drivers on 0.5% of machines_

Ahem. I have yet to see a linux machine where flash _doesn't_ crash
constantly. I strongly doubt the platform inconsistencies are due to a willful
decision from either Macromedia or Adobe. I'd say there is simply incompetence
and neglect at work here, "who cares about that 1% linux users anyways".

 _Speaking of which, if you want any specific feedback forwarded to said Linux
maintainer, I can do so ;)_

Adobe needs to learn that a significant portion of developers (not end-users)
do all their work and testing on linux machines. By denying these developers a
reasonable flash expirience Adobe is negatively influencing more platform
decisions than they can probably imagine.

Flash is completely out of the consideration for most linux developers because
for them it's not the fluid expirience you see on Mac or Windows, for them
it's "that nasty thing that always freezes and crashes".

Pissing off the top 1% of your most important target audience (developers!)
like that is, well, not exactly smart.

