Tech Blog

Last week we released a new Floorplanner account, the Enterprise account. With it, companies can have an online Floorplanner solution completely branded to their wishes. It includes the Roomplanner module and a custom library of their own furniture elements.  Steelcase and Maxon are the first to have an active Enterprise account.

The interesting part of this release, from a tech point of view, is the new drag-and-drop functionality. The Roomplanner is running in the Flash Player. However, the library of furniture elements is in HTML. We chose to build the furniture library in the HTML sidebar for a couple of reasons. It’s not in the Roomplanner, so there is more space left to design. It gives us more freedom in the page layout. All items on the page are indexed and things like sorting and tags we’re easier to build in Ruby on Rails than in Flash.

Now we only needed a way to get the furniture from the sidebar to the Roomplanner. That’s where the drag’n'drop comes in, drag from HTML and drop in Flash. To drag an image of a furniture element in HTML we used the fantastic JavaScript script.aculo.us framework. The next step was to swap the image to an element in the Roomplanner and to update the position of the element while moving the cursor on the Flash content. For this we used ExternalInterface to communicate between JavaScript and ActionScript. That’s all there is to it. The theory is actually quite simple, but in practice it was very (I repeat, VERY) difficult to get it working in all the main browsers. All those nitty gritty browser details…

At this moment everything seems to work just fine, so please take a look at Steelcase and/or Maxon and let me know what you think!

Last week I started working on a new version of the print functionality in Floorplanner. The problem with the previous version was that it didn’t print shadows, it was impossible to rotate the plan to landscape and textures didn’t look very well. Overall it produced a very mediocre image compared to the visual quality of a plan on the screen. As can be seen below:

Old print output

For printing we use the AS2 PrintJob class, which works really easy, with a small disadvantage: it doesn’t print Floorplans properly. I tried all kinds of settings for this class, with as input just a MovieClip with a drawing of the plan on it. I tried setting the printAsBitmap to true and false, both giving the exact same result. So although being stuck with it, the printAsBitmap boolean inspired me to investigate the Bitmap thing. We already had an image export utility, which produces images of a Floorplan with the same quality as it is shown in the FlashPlayer. The funny thing is that when I printed this exported image, the print quality was really good, at least a lot better than our own printing functionality. So for some reason, even if I used the printAsBitmap functionality, it still didn’t produce the same quality as using a real bitmap.
Of course we could have stopped here and just tell the users of Floorplanner to print the exported image. But since we are Floorplanner, we didn’t want to introduce another step requiring user action in the printing process, after all, we are the “easiest way” :-).
So I decided to use the same BitmapData created for the image export as basis for the printing. The first results where rather disappointing, I attached the created BitmapData to a MovieClip which in turn was given to the PrintJob. The produced print was of really low quality, you could easily see pixels all over the place. I tried using more pixels but now I bumped into the pixel limit of BitmapData (2880×2880 pixels). To work around this I invented the BigBitmapData class, this is a wrapper class that mimics the functionality of the BitmapData class, but which doesn’t have an upper limit of the number of pixels which can be used. When an instance of BitBitmapData is created which is bigger than 2880 by 2880, it creates additional BitmapDatas to store the additional pixels needed. So in fact the BigBitmapData internally stores an two dimensional array of BitmapDatas to bypass the pixel limit.
So with this new class I was able to scale up the created image to unprecedented sizes. I did a lot of printing experiments with scaling of the input, I tried scaling settings from 2 times to more than 10 times! This huge bitmap was attached to a MovieClip which in turn had to be scaled to fit on one single page of the printer. These values did give a better result, but still not good enough. It turned out that I had to take the DPI of the printer into account. The optimal scale factor turned out to be (1 / 72) * 300. The 72 is the DPI of the screen, and the 300 is the DPI of the printer. Furthermore a ‘point’ (print unit of measurement) is 1/72 inch, while the size of a pixel (screen unit of measurement) is dependent on the resolution of the screen.
So what this method actually does is creating a big image (which is resized to the paper contents) with enough quality to be printable on a 300 DPI printer.

New print output

So as you can see in the second image above, the new print looks a lot better, and since the new print uses bitmaps it is really easy to rotate it to always produce a print that tries to fill the entire paper.

A disadvantage of this method is that it takes quite some computational power to compute all the pixels for the bitmap that is created in memory, so as a result the FlashPlayer and sometimes even the browser freezes for a moment. Although this isn’t very good, we thought this behavior is acceptable since the quality of the prints is much better than the previous ones and the freeze time is actually really short. If you are not convinced by the images (which is understandable since the quality difference can only be seen on paper), just check it out!

Today I learned a couple of new things about the use (and trouble) of BitmapData in combination with loading content from other domains. I thought we solved it a while ago, but it in some situations it didn’t work… I definitely hope this is my last post about the subject!

When you load content from another domain and you want to use BitmapData, then you always have to load a policy file (crossdomain.xml) from that other domain. What I discovered today is that you have to do this for ALL the content you’re loading, otherwise the BitmapData just doesn’t work. Even if it’s content you don’t want to use for the BitmapData, you still need to load the policy file. It took me quite a while of debugging to figure this out.

This is our current setup. Every server has its own domain.

The other thing I learned today is a small trick to remove the Warning in your logs. Jeffry Houser explains it in his post Fixing your CrossDomain.xml File.

It took us some time, but now we see the virtues of JSON. We’re moving from XML to JSON to communicate with the outside world. The Floorplanner 2D app is (still) AS2 and I’m very happy to see that 5etdemi created a nice JSON parser in AS2.

Saves me a lot of work, thanks!

Since recently we create a thumbnail image of every Floorplanner plan that is saved. To create a 240×180px image we use the BitmapData class (AS2) to get the pixel info and we send it to our server to create the PNG/JPG.

It can happen that the content (images, swf’s) has to be loaded from a different server then the server that holds the HTML page with the Flash app. We noticed that the Flash Security Sandbox doesn’t like that (surprise!) by not allowing us to use the BitmapData.draw(..) method.

Abdul found a solution for AS3 and we ported it to AS2. We only needed a way to load the crossdomain.xml file from the domain of the HTML page. This sniplet uses Javascript to determine the domain and loads the policy file (crossdomain.xml) from it.

1
2
3
4
5

var url:String =  String( ExternalInterface.call(
    "function(){ return document.location.href.toString();}"
));
var split:Array = lCurrentUrl.split( "/" );
System.security.loadPolicyFile( "http://"+ split[2] +"/crossdomain.xml" );

The Flash Player on OS X currently lacks support for mousewheel events. This means that users cannot use their mousewheel on OS X, in the Floorplanner we use the mousewheel to easily zoom in to your Floorplan. After reading this post from pixelbreaker, I was inspired to implement this in the Floorplanner which was, in fact, very easy. I decided to only use the JavaScript class of pixelbreaker, which sends the mousewheel events to the Flash Player (on the Mac). In the Floorplanner ActionScript this event is handled by our own internal Event management system, which sends the Event to the reponsible part of the code. So thumbs up for pixelbreaker, for making this really easy to implement!

I’m currently working on a JSON export from the Floorplanner and I’m glad I found the excelent JSON Validator made by arc90 lab. They made the debugging process a lot easier. Thanks guys!

In college I followed a course in numerical analysis. The main point of the course was to be careful with floating point arithmetic, because it is vulnerable to rounding errors that can significantly influence the result of complex computations. Until yesterday I never had encountered such a problem. Now that I have lost my innocence in this matter, I would like to share my tale of nasty debugging and frustration.

After receiving some bug reports of Floorplanner designs that failed to save properly, we dove into the code to see what was going wrong. After some time, we found that the errors were caused by the script that loads the design after it has been saved with a unique name. This unique name is passed to the script to be able to find the design. We used the current timestamp as a unique name for the design. The current timestamp simply is the number of seconds passed since January 1, 1970 and looks something like this: 1206712028. As a design name, this number was passed to different scripts, both client-side and server-side. However, at some point in this chain of scripts, the number was changed slightly to 1206712030 and because of this the associated design could not be found, resulting in an error.

At first, we investigated the possibility that the stored timestamp was overwritten by a newer timestamp, as this could explain the slight increase in the number. However, we were not able to find this anywhere in the code and sometimes, the number was decreased a bit instead of being increased.

Finally, we monitored the data being sent between the different scripts, and we found that ActionScript automatically converted the numeric design name into a number in scientific notation. In our case, this would be 0.1206712028 x 10^10. Unfortunately, this number was rounded to 0.120671203 x 10^10 because computers use floating point arithmetic to store numbers in scientific notation. This number would eventually be converted back to normal notation, but it was now 1206712030 because of the rounding error.

We fixed it by putting an ‘a’ in front of the timestamp, preventing the automatic conversion to a number. Not very elegant, but it works!

Last week we wanted to see if we could speed up the loading of the Floorplanner Flash app. The Flash app (AS2) consists of 1 main app that loads several swf forms (the windows you see, like the library). The library itself holds a lot of furniture elements, which are separate swf files that are loaded one by one.

When a user creates a floor plan and adds furniture to it, it’s not strange that the design holds more than 50 furniture elements. Though all elements are small swf files, it takes a lot of time to handle all resource requests on our server. We thought it would be nice if we didn’t have to load all the elements one by one, but that we could bundle them into one big swf file. Then the generated bundle-swf is loaded into the flash app and the furniture elements are loaded from the bundle-swf.

We looked at Swfmill and Ming, and we did manage to create a setup that could dynamically bundle the furniture elements into one big swf. The problem was that it didn’t work for all our furniture elements. Almost 10% failed.

In the Flash app we also experienced some unexpected issues. You can only add mc’s (furniture elements) from the library to the stage by using attachMovie(). That means that all elements must have the same parent mc (AS2). So you can only use one bundle-swf, because if you load another, your attached mc’s will be removed.

With all the issues we encountered we decided to keep things as they are right now, and tackle this issue when we’re upgrading to AS3.

In my previous post I thought that swfobject was causing the wmode=transparent problem in IE. However, I was wrong. Folkert told me that swfobject only passes the parameter to the Flash Player, swfobject is only the messenger.

Instead of wmode=transparent I also tried wmode=opaque as Jorrit suggested, but it didn’t make a difference. I set up three wmode sample pages to test the issue:

• regular
• transparent
• opaque

When you’re viewing the transparent and the opaque page in Internet Explorer you can see that editing the walls is quite difficult. You can also see that panning the design results in a strange elastic movement. I hope to find a solution soon….

Update
I’ve been reading this post and it looks like it’s something we have to live with…

SWFs using wmode actually perform slightly different from SWFs that have a default wmode. The difference is that when you are running as transparent or opaque, events are delayed until an onEnterFrame. If you are running at a slow frame rate and drive your movie with setInterval or use any number of other events, you are back to your slow frame rate. The real kicker is that SWFs in IE have this bug. SWFs in Firefox are just fine.