4 ms·

Hacking SWF – Everything You Never Wanted To Know About Shapes In Flash

21 points by jgalvez 17y ago

chipsy 17y ago
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 17y ago
  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 17y ago
    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.
- gb 17y ago
  Can you explain a bit more what you mean about drawing white shapes? I've never had a problem: graphics.beginFill(0xFFFFFF); graphics.drawRect(10, 10, 100, 100); graphics.endFill();
  - chipsy 17y ago
    I made a mistake in the original problem definition. Try: graphics.beginFill(0xFFFFFFFF); graphics.drawRect(10, 10, 100, 100); graphics.endFill(); The extra "FF" for alpha triggers it. But change any one of the entries to FE and it's fixed again. Edit(2): I just realized that this must stem from the behavior of Flash's unsigned 32-bit integers. Doubly odd since you'd think they'd mention this.
    - iron_ball 17y ago
      A workaround is to specify only 0xFFFFFF; the last byte will default to FF (255), zero transparency.
    - cjbos 17y ago
      If you want to add alpha use the alpha parameter, don't specify it in the color value. The API makes a point of saying the color format is 0xRRGGBB. Use this instead: graphics.beginFill(0xFFFFFF, 0.5); //50% Alpha
    - gb 17y ago
      Ah, okay. I usually use the second argument of beginFill for specifying the alpha. Flash has quite a few quirks with Number vs int vs uint (it tends to switch types internally) so it could well be something to do with that. In fact, 0xFFFFFFFF is one of these cases: var n:uint = 0xFFFFFFFF; trace(n, getQualifiedClassName(n)); // result: 4294967295 Number

21 points by jgalvez 17y ago

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 17y ago
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 17y ago
  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.
gb 17y ago
Can you explain a bit more what you mean about drawing white shapes? I've never had a problem: graphics.beginFill(0xFFFFFF); graphics.drawRect(10, 10, 100, 100); graphics.endFill();
- chipsy 17y ago
  I made a mistake in the original problem definition. Try: graphics.beginFill(0xFFFFFFFF); graphics.drawRect(10, 10, 100, 100); graphics.endFill(); The extra "FF" for alpha triggers it. But change any one of the entries to FE and it's fixed again. Edit(2): I just realized that this must stem from the behavior of Flash's unsigned 32-bit integers. Doubly odd since you'd think they'd mention this.
  - iron_ball 17y ago
    A workaround is to specify only 0xFFFFFF; the last byte will default to FF (255), zero transparency.
  - cjbos 17y ago
    If you want to add alpha use the alpha parameter, don't specify it in the color value. The API makes a point of saying the color format is 0xRRGGBB. Use this instead: graphics.beginFill(0xFFFFFF, 0.5); //50% Alpha
  - gb 17y ago
    Ah, okay. I usually use the second argument of beginFill for specifying the alpha. Flash has quite a few quirks with Number vs int vs uint (it tends to switch types internally) so it could well be something to do with that. In fact, 0xFFFFFFFF is one of these cases: var n:uint = 0xFFFFFFFF; trace(n, getQualifiedClassName(n)); // result: 4294967295 Number