Tag Archives: javascript

Render SWF in JavaScript – a solution for Flash on iPhone/iPad?

Looking at the blazing-fast JavaScript in IE9 Preview 4 made me wonder if anyone had tried to write a SWF renderer in JavaScript. SWF is the Adobe Flash file format and a published specification.

Of course someone has. Tobias Schneider has been working on Gordon and built his first full release in June.

image

Gordon is a little behind in terms of version support:

In this build, Gordon can read and parse all valid SWF’s, even if they are compressed with ZLIB, but plays only SWF1 files completely, as well as the most of the SWF2 features.

The Adobe SWF specification is now up to version 10.

It is still an interesting exercise. Consider Google Web Toolkit, which compiles Java to JavaScript. What if Adobe did something similar for Flash? In fact, if you look at the Smart Paste “sneak peak” from Adobe Max 09 something like this was demonstrated.

The Flash player includes some proprietary codecs that could not easily be replicated in JavaScript. Still, given such limitations, “Export to HTML 5” would be a nice option to find on some future version of Flash Professional, and would help Adobe’s tools business even if it also dented its ambitions for Flash as the universal runtime.

Speeding page load with dynamic JavaScript

I’m delighted that ITWriting.com is sufficiently popular to sustain some advertising. I’m not pleased though with the impact on performance. The problem is that ads such as those from Google Adsense or Blogads are delivered by remote scripts. It usually looks something like this in the HTML:

<script type="text/javascript"
  src="http://some/remote/script.js">
</script>

When the browser encounters this script, it stops and waits until the script returns. This means that your site’s performance depends on the performance of the site serving the script. At times I’ve noticed significant slowdown – though to be fair, Google is normally faster than most others in my experience.

So how can this be fixed? I’ve spent some time on the problem, but with limited success. Ideally I’d like an Ajax-y solution where the ads flow in after the rest of the page had loaded and rendered, because the content is more important than the ads. The first step though is to place the scripts at the end of the page, so that the rest of the content is downloaded first. However, the ads have to appear towards the top of the page, otherwise the advertisers will not be happy. I tried inserting the script dynamically like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var theScript = document.createElement("script");
theScript.type="text/javascript";
theScript.src = "http://some/remote/script.js"; 
addiv.appendChild(theScript);

While this works after a fashion, it does not do the job. The problem is that the script typically calls document.write. If you are lucky, the ad will appear at the bottom of the page. If you are unlucky, the ad will replace the entire page.

What I needed to do is to capture the output sent to document.write and then insert the HTML dynamically. It turns out that JavaScript makes this easy. We can simply override document.write with our own function. Like so:

var addiv = document.getElementById("addiv"); //where the ad is  to appear
var adHtml = ”;
var oldWrite = document.write;
document.write = function(str)
{
    adHtml += str;
}
<script type="text/javascript"
  src="http://some/remote/script.js">
</script>
document.write = oldWrite;
addiv.innerHTML = adHtml;

This is brilliant, and in fact works perfectly for some of my ad scripts. Unfortunately it does not work for the slowest performer. The problem is that I have no control over the content of the remote script. In the non-working case, the remote script does not return HTML. It returns another script, which references another remote script. Now I have to figure out how to handle all the possible cases where scripts return scripts, which might or might not call document.write.

I’d be interested if anyone has a generic solution. There is a library here that looks like it might be helpful.

Another reflection is that it is in the interests both of advertisers and publishers to have scripts that execute fast and/or behave in a predictable manner that is friendly towards deferred loading techniques. It is no use writing convoluted code to deal with a particular script, when it might change at any time and break the site.

Slow JavaScript on Apple iPad?

Charlie Wood reports that his MacBook Pro is 26.7 times faster than his iPad at the SunSpider JavaScript benchmark.

I thought it would be interesting to put the iPad up against something more comparable, the Atom-powered Toshiba NB300 Netbook I’ve been using and enjoying for the last few weeks. I installed Safari and ran SunSpider, running on batteries. The result: the Toshiba is 4.52 times faster.

TEST                   COMPARISON            FROM                 TO             DETAILS

=====================================================================

** TOTAL **: 4.52x as fast 10999.0ms +/- 0.7% 2434.6ms +/- 4.7% significant

A lot slower than the MacBook Pro of course. Still, the iPad starts at $499. The NB300 is around $325.00 – though lacking that lovely touch screen. By way of compensation, it has a rather good keyboard, on which I am typing this post.

Note: I do not yet have an iPad so I’m relying on Wood’s test.

Why programmers should study Microsoft’s random failure and not trust Google search

The bizarre story of the EU-mandated Windows browser choice screen took an unexpected twist recently when it was noticed that the order of the browsers was not truly random.

image

IBM’s Rob Weir was not the first to spot the problem, but did a great job in writing it up, both when initially observed and after it was fixed by Microsoft.

It was an algorithm error, a piece of code that did not return the results the programmer intended.

Unless Microsoft chooses to tell us, there is no way to tell how the error happened. However, as Weir and others observe, it may be significant that a Google search for something like Javascript random sort immediately gets you sample code that has the same error. Further, the error is not immediately obvious, making it particularly dangerous.

I am sure I am not the only person to turn to Google when confronted with some programming task that requires some research. In general, it is a great resource; and Google’s own algorithms help a little with filtering the results so that sites with better reputation or more inbound links come higher in the results.

Still, what this case illustrates – though accepting again that we do not know how the error occurred in this instance – is that pasting code from a Google search into your project without fully understanding and testing it does not always work. Subtle bugs like this one, which may go unnoticed for a long time, can have severe consequences. Randomisation is used in security code, for example.

As an aside, there also seems to be some randomness in the appearance of the browser choice screen. It turned up on my laptop, but not on my desktop, although both have IE as the default.

And who would have guessed that the EU would arrange for so many of us to get an ad for something like the GreenBrowser popping up on our desktop? Apparently it is the “best choice of flexible and powerful green web browser”, though since it is based on IE it is less radical a choice than it first seems.

image