This is Not the Blog You're Looking For

Fullscreen Flash on OSX

2009-08-12T13:08:00.000-07:00

If you're having trouble getting true fullscreen flash in OSX, I have a solution for you.

The following code:

stage.displayState='fullScreen';

*should* set your flash clip to flawless fullscreen mode, and does in most OSes. Using OSX Leopard and Flash CS3, however, your flash clip still has the title bar (with the close, minimize, and + buttons). Not exactly behavior as documented.

At first I found the suggestion here to put the above code into frame 2 - that seemed to work for some people. That didn't work for me, but if I put a 530 millisecond or greater delay in frame 1 before moving on to frame 2 it would work (529 or less would not):


stop();
function goNext(te:TimerEvent):void
{
    t.stop();
    t.removeEventListener(flash.events.TimerEvent.TIMER, goNext);
    gotoAndStop(2);
}
var t:Timer = new Timer(530, 1);
t.addEventListener(flash.events.TimerEvent.TIMER, goNext);
t.start();

I then tried putting fullscreen code directly in goNext just to see what would happen:


stop();
function goNext(te:TimerEvent):void
{
  t.stop();
  t.removeEventListener(flash.events.TimerEvent.TIMER, goNext);
  stage.displayState='fullScreen';
}
var t:Timer = new Timer(530, 1);
t.addEventListener(flash.events.TimerEvent.TIMER, goNext);
t.start();

That didn't work, which meant either Flash really liked having that code in frame 2, or it just took that little bit longer to transition to frame 2 than it did to just run stage.displayState='fullScreen' inline. So I switched the delay to a full second:


stop();
function goNext(te:TimerEvent):void
{
  t.stop();
  t.removeEventListener(flash.events.TimerEvent.TIMER, goNext);
  stage.displayState='fullScreen';
}
var t:Timer = new Timer(1000, 1);
t.addEventListener(flash.events.TimerEvent.TIMER, goNext);
t.start();

... and it once again worked.

So it looks like the problem is we're waiting for either OSX or Flash to do something in the background before it's ready to go fullscreen. Until this bug is fixed you're going to have to take a good guess at about how long to delay before going fullscreen if you don't want to end up with a titlebar.

Yet another great trick with apt-get

2009-03-10T12:26:00.000-07:00

I recently bought a new virtual private server to host some web sites on. I use debian derivatives for all my hosting, but the server derivatives usually come pretty stripped down by default. So while I was setting my shiny new server up I got to thinking "there has to be some way to clone my installed packages off my older server".

Turns out, as usual, apt delivers!

1. Back up /etc/apt/sources.list on your new server: jwoffenden@newserver# sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
2. Copy it over from your old one: jwoffenden@oldserver# scp /etc/apt/sources.list root@newserver:/etc/apt/sources.list
3. Update apt: jwoffenden@newserver# sudo apt-get update

And then here's the magic:

1. Store your currently installed packages list in a file: jwoffenden@oldserver# dpkg --get-selections > ~/selectionfile
2. Copy it to the new server: jwoffenden@oldserver# scp ~/selectionfile root@newserver:/root/selectionfile
3. Tell apt to sickem!!: root@newserver dpkg --set-selections < /root/selectionfile && apt-get dselect-upgrade

4. Go get a snack. When you get back all your shiny packages will be installed.

Actionscript 3 and the JVM

2008-08-06T16:17:00.000-07:00

I've recently been ridiculed multiple times by uninformed Java developers for claiming that Actionscript3 runs on the Java Virtual Machine. In particular, the people in ##java got quite miffed at me for suggesting there was a relationship.

I'll admit I was fuzzy on the details of the relationship between Flash CS3 and Java, and searching didn't reveal anything that conclusive. Was it a built in, stripped down, modified version? Was it licensed from Sun or grown in-house at Adobe? I can't find it offhand, but a benchmark comparing Ationscript 1 through 3, Javascript, and Java revealed suspiciously similar numbers between AS3 and Java. Also Flex uses the ANT build system, which is a Sun/Java related animal.

So there was a blurry but definite relationship between the two in my mind. I stumbled on a lot more conclusive evidence while solving an elusive failure in Flash CS3's optimizer, though.

At least for Actionscript 3 projects, Flash CS3 compiles your code down to Java bytecode. It uses the Java compiler, the Java optimizer, and runs on an unmodified Sun Java Virtual Machine. The only part of the process that is any different from actual Java itself is the parser, and that's not all that different - as of AS3, Actionscript sure resembles Java a lot.

Single inheiritance, multiple interface, object oriented, strongly typed (well, you can get away with more loose typing but it's discouraged), packages, etc. It's not drastically different.

So this has me wondering - how many Java debugging tools, decompilers, etc could be used with Flash .swf's with very little jerry rigging...

Giving Flash CS3's compiler a little breathing room

2008-08-05T18:47:00.000-07:00

If you've ever worked on a decent sized (100,000+ line) project in Flash CS3, you may have run into situations where you can't compile with optimizations turned on: it either gives you bizarre errors or gives you a blank .swf. Sometimes you can't compile at all with or without optimization, or have to disable traces, and even then you may not succeed to build. It gives you cryptic feedback like "error generating bytecode" or sometimes no error at all. Frustrating.

I've done contract work on a few such projects, and it's a serious pain in the butt - nobody seems to have any answers save for "make your program smaller". Great.

There were plenty of rumors on how to fix it most of which involved doing magical dances with your fingers crossed (like rebooting and just hoping it works). None of them worked well or often, and finally today I set out to get to the bottom of it.

Since Actionscript 3 compiles down to Java bytecode and the default max heap size for the Java runtime environment is 128MB, I figured it was likely that the JVM was running out of memory and dying during the optimization phase. Armed with a similar hunch from a colleague (the Fu), I figured maybe giving Java a little more breathing room would fix the problem.

You can change the max heap size for the JVM with the command line option -Xmx, how do we get Flash to pass arguments to the JVM?

In the end, you can't. There's no way to get Flash to pass custom command line options to the java compiler.

It was just this kind of thing that the JAVA_TOOL_OPTIONS environment variable is there for. It watches over us, lovingly passing our guidance to the JVM when we can't do it directly.

When a JVM is being instantiated it checks the environment variable JAVA_TOOL_OPTIONS and treats it exactly as if it was passed at the command line. So now we can pass our beloved -Xmx1024M to the compiler and increase our max heap size from 128MB to a gig, and bam - we can compile with optimizations now.

To set the JAVA_TOOL_OPTIONS environment variable (in Windows), right click my computer->properties, open the "advanced" tab and click "environment variables". Hit "new" for either system or user - it doesn't really matter which you use unless you have multiple people using the computer. Enter JAVA_TOOL_OPTIONS for the variable name and -Xmx512M, -Xmx256M, -Xmx1024M, whatever. Oh, and don't forget the M :-)

This is how to set environment variables in OSX.

Happy compiling. We're not done yet though: there are a few gotchas.

The maximum heap size you can get in Java is 2 gigs, but -Xmx2G bails with a failed allocation. The highest value you can give without the jvm bailing is 1640M. That's right: 1641 kills it. Why 1640? Because Sun hates us, that's why. No really I have no idea why. *edit* The Fu informed me that on the Vista machine on which he tested this, it wouldn't work with anything above 1024M. When I got 1640M to work it was on XP SP2 in a virtual machine. I'm curious what the limit is on OSX.
If you enter any malformed, invalid, or otherwise "sketchy" options Java will fail to create its virtual machine, and Flash will freak out and tell you that you need to reinstall Flash. You can make everything better again by just deleting the JAVA_TOOL_OPTIONS environment variable.
If the JVM keeps dying and making Flash sad, open up a command prompt, head to C:\Program Files\Adobe\Flash CS3\JVM\bin and type "java". Hopefully you'll get some helpful feedback about exactly why Java's dying.
There is no number 4.

I hope this helps someone, because it sure would have saved me a lot of time if I'd known this before.