Mapping coordinates from one range to another in ActionScript 3.0

I am very fond of Processing, and the way it easily makes it possible to experiment with design ideas. One of the powerful features are it’s map() function, that takes a value and remaps it from one range to another. I haven’t seen a similar function in the ActionScript 3.0 reference, so I decided to make one to my own utils-library, because it is something the can come in handy in many situations. First I looked at using the Point() class, and interpolation to describe the ratios, but actually found it easier to just do it with regular math.

I haven’t looked at performance yet, and there is possibly a lot of ways to optimize this code – this article can be a start for further fine tuning. The helper function looks like this:

function map(val:Number, inMin:Number, inMax:Number, outMin:Number, outMax:Number, decimals:uint=0):Number
{
var returnVal:Number;
 
// Sets the total range for both in and out
var inRange:Number = inMax - inMin;
var outRange:Number = outMax - outMin;
 
//calculates the ratio for the value in relation to the in range
var ratio:Number = (val - inMin)/inRange;
//makes sure that the value is within range
val = Math.max(inMin, val);
val = Math.min(inMax, val);
//Finds the same ratio in the out range and shift it into place
returnVal = (outRange * ratio) + outMin;
 
//rounding of the decimals
var factor:int = Math.pow(10,decimals);
returnVal = Math.round(returnVal*factor)/factor;
 
return returnVal;
}

The function takes the the following arguments:

  • val: the number to be remapped
  • inMin and inMax: The original range, in which the value is measures in relation to.
  • outMin and outMax: The destination range, that the value will be re-mapped to
  • decimals: sets the precision in decimals (optional)
First it calculates the ranges with
var inRange:Number = inMax - inMin;
var outRange:Number = outMax - outMin;
These variables are defining the total range for both the incoming number, and the range of number is eventually will be placed within.
val = Math.max(inMin, val);
val = Math.min(inMax, val);
In this function I have decided to make sure, that the value is within the boundaries of the inRange. If i took the value 4, and sets the range of number to be within 10 and 100, I would get some unexpected results. You could treat this differently, or even make it possible by omitting these lines.
var ratio:Number = (val - inMin)/inRange;
ratio holds a number between 0 and 1 that defines where in the original range it is located. The closer to zero it gets, the lower the value – closer to one goes towards inMax.
returnVal = (outRange * ratio) + outMin;
Then the number is multiplied to the outRange to find the same relative point in the target range, and finally shifted into place by adding the outMin value. Negative values are treated fine in these ranges – when you add -200 to something, it is actually subtracted from the number.
var factor:int = Math.pow(10,decimals);
returnVal = Math.round(returnVal*factor)/factor;
The last part of the function is meant to round of the values. For performance, this could easily be removed, but it may be useful in some cases to have odd long numbers rounded and presented with only a few digits precition. First, the variable factor holds the value to be used in the rounding proces. For 1 digit it should be “10″, 2 digits is “100″, 3 is “1000″ and so forth. That value is used in the line below, where it first multiplies the final value by the factor and then rounds it to an integer. Then it divides with the factor again. It goes something like this:
  1. factor is 1000 (3 digits)
  2. value is 134.744637
  3. Multiplication results in 134744.637
  4. Rounding returns 134745
  5. divided by 1000 gives the result 134.745
Finally the value is returned as a Number.

Optimization

There are a lot of code shortening, that can produce a speed improvement. You could also work with int or uint exclusively to gain some performance i suppose. Finally, you can remove the decimals and the lines that check if the number is in range. I have left the to show what functionality that could come in handy.

An example

As a practical example of the map() function you can  copy the following code into a Flash document. Here the map() fuction is directly inside the main code, but you could start building your own utils-library with the helper functions as public static function for easier access.
The code draws two squares with different sizes. When the mouse moves over the small square, it draw lines in the larger square, while maintaining the relative coordinates inside the squares.
import flash.display.Sprite;
import flash.events.MouseEvent;
 
//make the small square and color it dark grey
var inArea:Sprite = new Sprite();
inArea.graphics.beginFill(0x333333);
inArea.graphics.drawRect(0,0,100, 100);
inArea.graphics.endFill();
addChild(inArea);
 
//make the large square and color it black
var outArea:Sprite = new Sprite();
outArea.graphics.beginFill(0x000000);
outArea.graphics.drawRect(0,0,400,400);
outArea.graphics.endFill();
outArea.graphics.lineStyle(1, 0xFFFFFF, 0.3);
addChild(outArea);
outArea.x = inArea.width;
 
//adds a listener for the small square, that listens for mouse movement
inArea.addEventListener(MouseEvent.MOUSE_MOVE, updateDrawing, false, 0, true);
function updateDrawing(event:MouseEvent):void
{
	//Map the local coordinates from the mouse movement to the size of the large square
	var targetX:int = map(event.localX, 0, event.target.width, 0, outArea.width);
	var targetY:int = map(event.localY, 0, event.target.height, 0, outArea.height);
 
	//Draws the line in the large square.
	outArea.graphics.lineTo(targetX, targetY);
}
 
//Helper function
function map(val:Number, inMin:Number, inMax:Number, outMin:Number, outMax:Number, decimals:uint=0):Number
{
	var returnVal:Number;
	// Sets the total range for both in and out
	var inRange:Number = inMax - inMin;
	var outRange:Number = outMax - outMin;
 
	//makes sure that the value is within range
	val = Math.max(inMin,val);
	val = Math.min(inMax,val);
 
	//calculates the ratio for the value in relation to the in range
	var ratio:Number = (val - inMin) / inRange;
 
	//Finds the same ratio in the out range and shift it into place
	returnVal = (outRange * ratio) + outMin;
 
	//rounding of the decimals
	var factor:int = Math.pow(10,decimals);
	returnVal = Math.round(returnVal*factor)/factor;
 
	return returnVal;
}

Adobe Flash and HTML5 – are we happy?

Days have passed, and I have deliberately not commented that much on the debate that has raged the net since Adobe Systems announced, that they wouldn’t continue the mobile Flash Player. What I have done, was observing the different phases of emotion that users where sharing with the rest of us. I saw mainly 3 categories: 1. Those who wan’t Flash dead yesterday, and didn’t think that this was one day too early. 2. Those who thought that this was the end of the World as we know it, and everything now turns to darker times (scenes with polluted cities and numb faceless people dragging them self around next to grey walls pops into my mind). 3. People with everything has it’s time – let’s see if it isn’t best for both part – sort of people. Let me first comment a bit on all three:

1. The “HA-HA. Dead by HTML5″-people

A lot of these people do not like Flash – no matter what it does … it is just pure evil. Some may have the program to crash their machine – other may just have heard of people who has a crash on their machine while Flash was installed. This group have made a choice not to support the platform on their device – or at all. If they have an iOS system, the choice is taken for them – they cannot decide for themselves. They see blank spots on websites, and think that the Internet should adapt to their needs and limitations (like iOS ever would the other way around) :-) The other part of the group are praising the open standards, and think that proprietary plug-ins are a bad thing – the Internet should be free, and no one should take ownership of any part of the experiences presented.

2. The “End of the world”-people

Well, Adobe did an awful job, communicating this announcement, and people just shimmed and was something like “OK, let’s see: Adobe announces … etc. etc. … Flash Pl… … Mobile … Discontinue … etc. etc. … Open  Web … Webkit … HTML5 ”

… AARRRRGH. Flash is dead. HTML5 killed it. Uuuh, Steve Jobs, you son of a #¤%#%& – are you happy now!! The next Apple fanboy that comes around, better be sorry or I’ll …

Well, maybe not that crazy, but a few words, where enough to make them go crazy, instead of rational thought of what their own mobile habits where. When we read what is gone, we also need to sum up, what is left. This has to be taken to a higher point of view, to understand the purposes (as I see them)

When Flash isn’t on mobile browsers, then whats next – desktop? … Linux? (oh, already) … AIR? … Illustrator and Photoshop?! Fact was, that the most recent Flash player on mobile browsers actually performed quite well on newer smartphones, so why? We wan’t the whole web. Everybody want the whole web – or do we?

3. The “Let’s see if it’s not for the best”-people

This group, have a habit of taking announcements up for consideration, and think of consequences and reasons for a given action. They may have various reasons for being in this group, but it could be something like: “I am not browsing that much on my phone – mostly searching information”, “I’m more into Apps”, “Drop all the fancy stuff, and give me some battery time back” or “HTML5 can do a lot of Flashy looking stuff – why not use that instead”.

A change in plans

When the iPhone came around, there was no Flash Player, that could stand up for The Jobs … so he turned it down. Having great interest in the Canvas-tag (read, previously patent, AFAIK), he thought that this was a better solution. Flash would lead to a poorer experience – how true that was. What he forgot to tell was, that it probably wasn’t solely a problem for the plug-in, but more a problem of bringing all the advanced stuff into a tiny phone with a tiny battery. You didn’t hear him say: “But that tends to be a general problem. We cannot do that with HTML5, either!” The fact was, that the advanced features of the Flash Player just didn’t fit well in these first generations of devices (both Android and iOS). Adobe thought that the “code once and deliver everywhere” should be adhered. They ported it to Android, that is more open than iOS and allows people to develop to the browser.

iOS on the other hand, had great success with the walled garden, and the term I call “iWay, or the highway”. In this closed ecosystem, things are taken care of for you, and you should have trouble doing all the things a computer should do … just what people wanted. Installation and removing Apps is easy … we actually think, that it cleans up, after itself, when we delete the App :-) Icons and folders for tools and games. Why go to the web to search for a recipe or play a game, when you can install and access it right on the phone – why use a browser for that, and remember URL’s etc.

Adobe was wrong, and realized it

Adobe kept trying to fulfill the promise of the full web, and code once and deliver everywhere. Apple said, they had the full web experience on iOS, ignoring the fact that it wasn’t true. And while the battle raged, and the fanboys where mooning each other, the normal users started to adapt and use the technology on it’s own premises.

Even though the possibility was there, no one created mobile specific solutions in Flash. You just couldn’t scale a website down to a little screen and bring the same experience from desktop to phone – Flash Player is a media container like video and images. It has a hard time, reflowing text or layout, when the browser size changes. When a demanding webpage finally came around, it was so FWA-like that it would pop out the battery from the back-cover on my device.

On the other hand, the user was downloading and shopping Apps in an extends hard to imagine. It was so easy to link to AppStore or Android Market from a website, and install directly on the phone. I have the feeling that a lot of users found it as an improvement to download an App from the site, to get some dedicated time with the content even after they have left the webpage.

The device isn’t ready

Flash has always been a plug-in for HTML and browsers. Images and video are easy to relate to HTML, but Flash is a bit harder. The main purpose of Flash is to take the user to experiences, the HTML can’t go. When HTML stops, Flash player is supposed to take over and deliver a media container, showing what’s really possible … but it is just a square on a web page. The demand for more and more sophisticated pages has previously driven HTML into the shadow, and made complete Flash-driven pages a viable solution, when trying to impress clients and end users.

Fact is: Devices sucks at that. Most devices can’t even handle HTML5 and canvas that well, and if we have a technology, that have more than enough to do with HTML in its newest revision, then there is no need for a “I’ll take over from here”-plugin like Flash.

Realizing that users didn’t used the browser on their mobile device for advanced content, but rather downloaded Apps, is for me a breaking point. Some tend to say that it was Steve Jobs, and his famous letter on Flash and his thoughts about it, that did the job. To some extend that may be right – not because he said it, but because his disciples kept preaching it as a gospel every time e person pushed the button. I think the main reason is that Apps came on strong, and users didn’t wan’t these complex operations in a floating window … not when it was performing like it did. Everything with App was fast and smooth, but the same experience on the net was not. I am convinced that we will not see any complex HTML5 solutions in browsers, before we have a completely new generation of devices in our hand.

fAIR solution

That leaves the net to HTML, and with HTML5 it has just brought more possibilities to the developers. Flash player is out of the browser (for some time at least) because it has nothing to do there. Flash Player 11.x is still there, so there will be plenty of possibilities for targeting mobile users in the future – don’t worry. But Adobe is taking Flash to places, where HTML5 cant go (at least not easily). The only place that can be done is on computers, that has more processing power, and a power cord, and to mobiles native applications. Only there, can Flash tap into the hardware that is needed to deliver great performance.

AIR is what’s taking care of that, and I think that it has a few advantages. If you target iOS native you are using Objective-C. If you are targeting Android, you are using Java. No developer on any of these platforms are able to deliver to the other side. AIR comes with the APPS-neutral AS3 language, that can be compiled to native Apps for both Android and iOS, and it is more and more important to support a wide range of platforms as the market shares levels out. Performance are better in native code, but I am pretty sure, that is a main focus for Adobe in the future.

Are we gonna play, or what?

games are another main aspect, that I see Adobe pays attention to. With the new 3D-capabilities and export functionality from Unity and other, I see browser based games on desktops as an interesting way to go. The way we play on a computer, is far from the way we entertain our self on a device – they cannot be matched. It is therefore Adobe is trying to make a plugin, that make games, independent on machine or browser, so you can develop a game, and make sure that all desktops can play it. How many games in HTML5 aren’t available, that only plays in Chrome or Safari etc. … I don’t think the browser war is ever gonna stop on that platform. When the player can utilize gamepads and joysticks, I think that we are going to see interesting games … and event sites, and company pages, that takes it to the max, and wouldn’t play on a desktop anyway.

Conclusion

I think that Adobes step is probably a way to “code once and deliver everywhere”. When Creative Suite next revision arrives (the six-pack) I think we will see Flash Professional, that takes the timeline and possibilities around that, and enables it to be converted to HTML5 – if that succeed, then what’s the harm. I mean, is it the player or the possibilities, that are most important. Then we will go way high on 3D and native App performance, and Flash as a platform is able to live on. Using HTML5 for mobile may be the only solution to “publish everywhere” in a non-plugin-browser-world.

I think that Adobe made a wise choice in taking the Flash Player out of market for a while. That can take all the browser Ads to HTML and get the devices to mature to a point, where there is more in the devices, that HTML5 can deliver. In the meantime Adobe can try to incorporate elements to HTML, that makes it easier to publish from Flash to HTML – CSS Shaders is a sign in that direction.

It all comes down to looking at behaviors, and identify objective, non-favored points of direction in them. I think that Adobe shifting focus here, is not a sign of weakness, but actually a sign of adapting to the users need – some companies could probably learn from that. Their skills in communicating, what I just tried here, is a completely different story. I am not saying, I do a great job here, but I know that Adobe didn’t.


Flash Platform is dead. Long live the Flash Platform

Adobe MAX has this year been an interesting and epic experience, in many ways. We have seen Adobe doing a lot of progress on the HTML5 platform, and no critiques can come and say, that they are trying to limit it’s possibilities in an attempt to favor Flash. Seing programs like Adobe Edge and Adobe Muse, shows a bright future for users, that are not tech-savy – bringing them new tools to make dynamic and interesting sites using web standards.

Some will say, that Flash is thereby obsolete. They may even use the “Flash-killer” word, but in my opinion that tells me more about there insight and knowledge about the platforms responsibilities, than HTML5 is superior when it comes to the sites of the future. HTML has always had the responsibility of bringing webpages to the user via the browser. The Flash Player has always been a plug-in, that made it possible to satisfy users demands in terms of interactivity, video etc. and complemented HTML, where it wasn’t sufficient. Now with HTML5, nothing has changed there.

The Flash Platform is dead

I will bring some love to new new HTML5 features in another post, but let me dvelve a bit on the head line. When I say, Flash is dead, I actually mean, the previous well known (and hated) use of the Flash Player is dead. Using Flash to make complete sites with the need of seekable information, and “efferent reading” has to stop. The small banners that pops up, with no reason at all, has to stop. If that is what you have used Flash  to produce, you should seriously consider broaden your mind – we have HTML for that, now. When it comes to aesthetic reading, engaging and entertaining the user. When it comes to breaking the boundaries, and search for new possibilities in what the web and devices can deliver, please continue. Flash has never intended to kill HTML, it depends on it. But the misuse  of technology from developers (myself included, from time to time) has given the technology a bad name.

Long live the Flash Platform

Fortunately, the platform is strong and very much alive, and the latest version of Adobe AIR and Flash Player brings signs of a bright future. When I discuss the topic with developers, they actually do not have a clear answer, when it comes to compatibility across multiple devices. Native Android developers, can’t enter en iOS sphere, and Xcode developers are forever doomed to live in the walled garden. Both of them, can only argue, that the other should join them … why not give the user a choice. I think that the Flash Platform is one of the best attempt to actually be agnostic in terms of platforms. I think it’s time to look at some of the features I find interesting

64-bit support

I don’t know what took them so long, actually. I am not aware of the complications that are involved in making 64-bit versions of software. I guess there must have been internal complications regarding codecs or other 32-bit stuff not yet upgraded or just the fact that making a 64-bit version of the AVM or the like isn’t a walk in the park. Anyway, now it’s available and works like a charm in my 64-bit version of Internet Explorer as well as my other browsers on both Windows and Mac OS. I haven’t tried the Linux version, but I haven’t heard anyone with complaints. Please post your experiences with performance, if you are a Linux user.

Captive runtime

Captive Runtime is captivating :-) Now developers have the choice to embed the AIR 3 runtime in the App, so people no longer need them as an external download. That, of course, brings a larger file to the devices, and it is therefore not just something you would do in all cases. In larger projects, and definitely on desktops, that seems like an obvious choice.

You can read about Captive runtime at http://www.adobe.com/devnet/air/articles/air3-install-and-deployment-options.html

Accelerated 2D

Flash is all about experiences. There is no need to use Flash, if you don’t wan’t to engage the users. If you just have some plain information to present, there is no need to roll out the big canons. The Flash Player is a plug-in that takes over, when the other give up, and can’t deliver – at least not with an economically reasonable solution. It is the easiest way to make impressive visual results, that works on all major platforms. Because of that, it is also a very demanding job, that takes a lot of processing power. With Flash Player 11 and AIR 3, Adobe has made it possible to port most of the calculations to the graphic card, so the processor is free to other tasks. That increases the performance immensely, all the previous examples (like those on http://www.bytearray.org/?p=3371) would have made the fan fly out of my MacBook Pro after 4 seconds … now there is silence.

One of the most prominent examples are the Starling Framework. Starling is very intuitive, and use well known word like Sprite and addChild() and genrally build upon the concept of the Display List.

To get this performance boost, Flash takes advantage of Stage 3D, and that is only available for desktops at the moment. Adobe is working hard to implement it in the mobile version, but Android have to wait until a later update. That also means, that we are in a time, where some content actually can’t be played on mobile, even though they are at the same player level … that’s not good, but hopefully sorted out in a near future.

JSON

Everybody is talking about JSON these days, and for a reason. The format makes it possible to exchange data in a readable way using a JavaScript like syntax. Both JavaScript and ActionScript 3.0 derives from the same standard, making it easier to work with and understand for some, in contrast to the XML language. You have always been able to read JSON into a Flash document, but the internal support makes is consistant and faster to get the data ready for use. Actually, we are are talking one line here to get it all parsed.

Adobe MAX gave a sneak at the next version of Flash (codename Reuben) that exported a sprite sheet of a characters walking cycle. That shows something about JSON as a serious and integrated way of making 2D games and motion in the years to come.

Stage 3D

When Flash introduced the ability to work with z-coordinates and move 2D objects in a 3D space (in CS4 i guess) the crowd went wild – everybody was happy. Then they realized, that i actually wasn’t as good as real 3D, and the need for manipulating real 3D objects was on the rise again. When Adobe released the first previews of Flash Player 11, it was jaw dropping. Thibault showed a red car driving around in a virtual street, and no one in the room could believe their eyes. But it was real, and with the release, they showed Unreal Tournament 3 from Epic Games, running in a browser.

That tells me, that the Flash Player has taken it’s responsability as a plug-in serious, and goes for the balls, that HTML5 has a hard time to catch. I am sure we are going to see web experiences in the years to come, that we had a hard time to imagine only a year ago. On top of Stage 3D’s low level API a range of external companies has build frameworks for us to use. Some of the well known are Alternativa, Flare3D and Away 3D. Of course you could dive into the low API, but the other way around is much easier for normal developers and designers.

Aside from that, there is a project called Proscenium on Adobe Labs, that is a code library used to acces the low-level API, to easely create 3D content in Flash Player 11.

Read more about the wonderful world of Stage 3D at http://www.adobe.com/devnet/flashplayer/stage3d.html

Native Extensions

On the mobile platform, there is a constant demand for speed and integration with the system. Native tools like Xcode and Android SDK has an advantage over runtimes like AIR, in that they have full control over the system. AIR isn’t able to access the inner workings of the mobile platform, so you could not access the local API. AIR it self is making progress, like native keyboard on devices and frontface camera access, but the big leap forward here is Native Extensions. Now you can program an extension to AIR in the native language of the device, and AIR is then able to attach to it and communicate with it. There has already been examples of Map View on iOS and connection to Kinect controller without a proxy. I haven’t tried native extensions in myself, but it seems like it’s going to be a big deal if it runs smoothly.

Content Protection

I love the way that HTML5 has taken websites seriously again. I like the easy way, that video is treated. If all browsers could agree on the codec, it could end up as a good solution. The problem is that there is no protection embedded with the video. You could just copy the link and download the movie. Many content providers aren’t that happy about that. There are solutions to solve that, but I sense that they are moving away from the clean HTML5 solution. Flash and AIR has build in Flash Access that secures the content. Initially it only works with desktop and Android, and I guess that the way into Apples heart is a bit longer :-)

Heal the Web, make it a better place

This is just some of the news. You can read more at the Flash Player 11 feature page and the AIR 3 feature page. This is an epic release, that will mark the start of a new era – the 3D era. We will se browsers taking HTML5 to the max, and transitions like fade and slide, will be everyday for the common designer. But when the smoke disappears, the need to do the extraordinary will emerge – this is where Flash kicks in. Flash Player will fulfill it’s role as the plug-in, that helps HTML getting things done. AIR is taking a different path down the mobile path. It is an interesting path, but it is not quite there yet. It is there in terms of being able to deliver a more than decent result on various devices, but the “works on Android, soon on iPhone” makes it not quite stable yet. It will be, hopefully soon.

I think that this release, shows that there is a world, where both technologies can live in harmony – and truly believe they will. We haven’t talked about topics like all the Smart TVs that supports the platform. We have only briefly talked about Epic Games, but Unity has also shown support to deliver on Stage3D. Aside from that, there is the Open Screen Project, that count a broad range of manufacturers , interested in making a common platform for Rich Internet Applications end experiences.

I know that the Flash Player aren’t allowed on iOS – well no plug-ins are, no harm there … but AIR are. AIR, may end up being a long term solution, if they fix the minor incompatibility. Flash Player is now a solid 64-bit plug-in, and yes – everybody is trying to find exploits and security breaches on it, but then again. It is on a lot of machines, end therefore a perfect target, across platforms. Adobe should be on it’s toes to close these security issues and gain trust in the platform, and then – when iOS settles at a reasonable level, the market will decide if users with the plug-in is more interesting than those without.

… only time will tell.


Calling a function dynamically in ActionScript 3.0

Have you ever wondered, how you could use a String to decide, which function to be called. You could go so far to let the user enter the function name in an input field and call a function by that name, if it exists.

I have made a short article with an example on how that is done in Flash and ActionScript 3.0. You can read the article at http://www.hjaelpmignu.dk/content/dynamic-call-functions


Adobe Creative Suite 5/5.5 – Printing guide

If you are using Adobe software to create design for print production or receive documents as a print provider, this guide is a must read for you. All relevant info on color handling, trapping, handling transparency and effects are there. Info on Job Definition Format (JDF) and how to print and edit PDF files is there. Best practise – what and how to expand objects in Illustrator are there. The Forensic Tools in the various software is explained.

All in all. 138 pages of action packed printing info available. Questions to the guide are welcomed in the forums

Link to guide

Happy reading


PANTONE Colors in Creative Suite – manual update

Update: After this post, PANTONE has made a new installer, addressing the issues. This post talks about the situation before the update in July. You can get the install files to Creative Suite at http://www.pantone.com/pages/Pantone/Pantone.aspx?pg=20721&ca=1 and to QuarkXPress at http://www.pantone.com/pages/Pantone/Pantone.aspx?pg=20727&ca=1 In addition to that you can read the PDF “PANTONE PLUS for Design and Production” for a guide on how to use the isntalled color libraries. Thanks to Doug, for the update.

PANTONE colors, where art thou? I was asked a question in the forums about the lack of a specific color (PANTONE color 7692 U) in the forums. I started to look in InDesign, where the question was posted, but no avail. Same result in the other programs in Adobe Creative Suite. A quick look at PANTONE color finder proved that the color was there alright. But then, why do newer versions of Adobe InDesign and other not have the current colors in their color book.

After trawling for info in forums, I found that there where a update called PANTONE® PLUS Digital Libraries for Adobe which should update the Creative Suite software to contain the newest swatches. I tried to update via the installers, but it didn’t make any of the files show up in the programs – It looks like it stopped somewhere around CS3. As a result, I ended up extracting all the files manually, organizing them into folders, and them copied the to the respective preset-folders. Can anyone enlighten me: Why isn’t these files part of the standard updates? PANTONE colors is relative important as a reference color library for many offline designers and print providers.

I collected all the files in a all the files so you can do the update manually. Instructions on where to put them as well as the original tech-note is also included.

I hope that this will close the gap until an official release is given from PANTONE or Adobe. Please, comment any feedback on errors so the files can be updated if needed.

Link to zip-archive (Updated to v1.1.1 date: 11/10/11)

UPDATE v1.1: I have updated the files, so they also contains colors for QuarkXpress – taken from http://www.pantone.com/pages/Pantone/Pantone.aspx?pg=20727. I do not have Quark myself, but believe that they should be placed in a folder called Color inside the app-folder

UPDATE v1.1.1: I have placed all nine aco-files in the Adobe Photoshop folder, and removed the acb-files.

 

Enjoy!


Adobe Edge about to caress HTML5 … again

By now, it should be clear that there is no resistance towards HTML5 and JavaScript from Adobes point of view. We have seen the HTML5 pack for Dreamweaver and Illustrator. I believe they did it as a proof of their true interest in the technologies surrounding the Internet. In addition to that, they didn’t wan’t designers to look elsewhere for tools to design and develop HTML content. Actually, Adobe has always paid interest in these technologies – it would be odd to have the most famous HTML-layout program and not being happy, when it evolves and taken advantage of it.

The update to CS5.5 gave further proof of a dedication toward mobile devices and open standards. We where shown massive update when it comes to mobile development. iOS had to catch up on the possibilities and performance that previously was introduced for the Android platform. Flash Builder and Flash CS5.5 took care of that. HTML5 and jQuery was fully incorporated in Dreamweaver CS5.5 in addition with a lot of other stuff, to bring even more effective workflows to designers trying to approach these new devices and technologies.

But then what … was that it. No, Adobe has an underlying piece of software under the hood. They had already shown that it is possible to take a Flash timeline animation and make it HTML5 compliant. It turned into a tool named Wallaby (working title) – it’s experimental but with a lot of potential for Flash users to leverage on their existing skills.

Aside of that, a brand new program with the working title Adobe Edge is in the making. We have seen technology previews of a prototyping tool, but it has grown to be a fully featured animation tool for HTML5 pages. You can se a short walkthrough where an image and svg file is animated for a start. Afterwards a fully designed HTML page is opened and given transitions to gently introduce the page elements. Everything is layered on top of the existing design, so you wont break the layout when collaborating with other designers.

I really like the way they managed to make the timeline integrate with the DOM elemements. We may end up having an animation tool for pure HTML designers that can match features used by the Flash timeline animators. The only thing we need to see is how well it will be integrated with programming logics and JS-development … maybe Dramweaver is up for another spin.

You can be notified about the public beta at http://www.adobe.com/go/edgepreview_notify and read more about the program at http://labs.adobe.com/technologies/edge/

The future is bright :-)


Det store dyk

Jeg har i den senere tid med interesse fulgt mange af de udviklinger som HTML5 og canvas elementet har bragt. Små ting som www.radiohead.com bringer stimulerende effekter og kører fint på mobile enheder. Problemet er at det er mere reglen end undtagelsen at performance på mobile enheder afviger markant fra laptop/desktop oplevelsen.

Det kræver i sig selv ikke meget at regne ud, da en mobil processor ikke har en reel chance mod en flerkernet CPU og dedikeret grafikkort. Hvis du vil dykke ned i nogle af de pæne eksempler kan du f.eks. kigge på:

Fantastiske muligheder for at udfolde sig, tårner sig op i horisonten, men det er netop disse mange muligheder som jeg frygter kan ende i det jeg har valgt at kalde “Det store dyk”.

Fremtidens medier bliver de oversete

I tidligere versioner af HTML. Det er egentlig forkert at skrive tidligere versioner om HTML 4.01 og XHTML, da de ret beset stadig er de aktuelle versioner, men snakken om HTML5 for alt andet til at føles som en fjern fortid. Med HTML4 var alle mobile enheder nye og spændende. Desktop platformen var domineret af Flash indhold, så snart tingene skulle røre sig ud af flækken – der var aldrig nogen reel mulighed for at overføre disse sites til dem der havde fået sig en mobil, der kunne besøge internetsider. Hvad var løsningen? Det var selvfølgelig at teste for om det var en telefon der viste siden og derefter at levere mobiloptimeret indhold. Prøv at besøg sider som cnn.com og du bliver omdirigeret til cnnmobile.com. Besøg tv2.dk og du bliver omdirigeret til deres mobile site. Denne tilgang blev brugt af et par årsager:

  1. Der var en begrænset skærmstørrelse
  2. Opløsningen var markant lavere
  3. Der var ingen fintfølende mus
  4. Der var ikke den samme hastighed i forbindelsen

Der var selvfølgelig også en række andre faktorer, med hensyn til muligheder for at bruge tastatur, det personlige forhold til browseren som telefonen giver, men ovenstående er vigtige i denne sammenhæng. Designere lavede deres sites som de plejede og vurderede derefter, hvilket indhold der var relevant på mobiler. Det resulterede i “mobiloptimerede” sites, der kun viste det absolut mest nødvendige. Sites, hvor tekst blev skåret til og billeder beskæret. Alle tiltag blev gjort for at dem med mobiler fik en god og effektiv oplevelse. På det tidspunkt var der mange penge i datatrafik, og mønterne rullede ud af pungen, hvis sitet var for tungt.

Computeren haltede efter for en stund

Med iPhone blev alt ændret. Udvalgte teleoperatorer fik lov til at servicere den – der skulle leveres en dataplan, der gav brugeren mulighed for at bruge 3G netværket med telefonen. Man kan sige at det var en iPod med telefon, men sammenlægningen af disse to ting gjorde at telefonen sparkede alle andre telefoner af banen. Sparkede MP3 afspillere af banen og sparkede smartphones som iPaq o. lign. af banen. Ikke at de andre bare forsvandt, men de kunne ikke konkurrere på specifikationer, og der var ingen af de andre, der havde formået at tvinge teleudbydere i knæ som Apple havde formået. Tilsæt en smule hype (eller spandevis af hype) og iPhones success var en realitet.

Spådomme om computerens endeligt flød, og senere udmeldingen om at Flash ikke kom til iOS, gjorde alt andet end iOS udvikling til perifære interesseområder. Snakken om hvordan det videre forløb (og stadig forløber) er et andet indlæg værdigt, men jeg vil med ovenstående nævne at en smartphone (iPhone) nu skulle have følgende faciliteter:

  1. En relativ stor skærmstørrelse
  2. En opløsning, der nærmede sig lave opløsninger på computere
  3. Muligheden for at trykke på skærmen, med en eller flere fingre
  4. Mulighed for både 3G og Wifi, samt effektiv synkronisering

Dette fik computeren til at sakke yderligere bagud i interesse, da muligheden for at tilgå viden overalt, gjorde selv den tyndeste laptop mindre relevant til en lang række opgaver. Derudover er telefonens “altid-tændt” natur, noget som batteritunge laptops ikke kunne forholde sig til. Forbrugsmønsteret ændrede sig lidt før den tid, så der kommer fokus på sociale og personlige relationer, samt deling af billeder og videoklip. Muligheden for at tage et billede, der hvor du var og uploade det så venner kunne se det, med det samme gjorde alt med ledning til et dårligt sats.

De nye browsere

Browserne havde barslet længe med at implementere HTML5, men en iPhone havde muligheden for at starte forfra og definere de muligheder som en smartphone havde når den besøgte et website. Den ville have “The best/full internet experience”. Mange tilhængere af Flash Playeren mente ikke at det var tilfældet, men de havde kun defragmenterede versioner af Flash Lite, der (mildt sagt) ikke performede særligt godt. Der var ikke rigtig nogle modargumenter, så iPhone blev det man kiggede til når man skulle arbejde på mobile platforme. iPhone havde webkit installeret, og der var ingen mulighed for andre udbydere af browsere at byde ind, så den har trukket meget af udviklingen og sørget for at de andre browsere på stationære og bærbare fik travlt.

Vi begynder at dykke

Flere devices kom til. Tablets og Android telefoner blev spyttet ud, og et kapløb om at levere den bedste ydelse, oplevelse og batteritid gik igang. De fleste bryster sig af mulighederne for at overtage computerens rolle … og lidt til. Opløsningen er nu kommet så højt op, og hukommelse og hastighed gør at normale besøg på nettet er en fornøjelse på en iPad (den eneste jeg har at referere til) og smartphones. Derudover matcher de nyeste udgaver af alle de store browsere mange af de HTML5 og CSS3 tiltag, der er under udarbejdele. Udviklingen er faktisk gået så hurtigt, at en ratificering af standarden er rykket fra 2022 til 2014 – det er en ordentlig mundfuld. Der er nu ikke mere den store forskel på de browsere der afvikler på computer og de browsere, der afvikler på Android og iPhone.

Skrid Flash. HTML5 er her

Ønsket med Flash har altid været at kunne udvikle i et miljø og levere interaktive oplevelser på alle platforme tilgængelige. Med Apples afvisning af plug-in’en ligner det en umulig opgave. Apple derimod slår på tromme, for HTML5 og dens muligheder for at overtage den proprietære plug-in. Canvas, Javascript samt CSS3, skal løfte arven og opfylde drømmen om en kode, der kører i alle browsere. Mulighederne og eksemplerne med HTML5 begynder at sprudle og minder delvist om dagene med Macromedia Flash 3, hvor grænser skulle søges og muligheder udforskes. Som browsere bliver udskiftet og begynder at opdatere vil alt dette pionerarbejde begynde at bære frugt. Vi er allerede begyndt at teste for muligheder i den besøgendes browser. Nu tester vi om det er den nyeste, og leverer lidt ekstra – før testede vi om den var for gammel og udelod noget.

“Det store dyk”

Med denne kamp om ligestilling, først fra smartphonen og siden computerens browser, gør at særstatus og hype på mobilen nedtonet og kun nævnt når der kommer nye og hurtigere modeller. Det er der ikke noget galt i, men det der kan ende galt er at designere og udviklere ser mindre fornuft i at lave synderlig specielle tiltag for at optimere andet en layoutet – HTML5 og JavaScript vil fungere på alle større platforme. Det er allerede tydelig at der bliver taget højde for at ændre CSS når browserstørrelsen er over eller under bestemte dimensioner – men hvad med koden og canvas elementet?

Mange af eksemplerne rundt om på nettet der beskæftiger sig med HTML5, canvas og JavaScript, sætter en ære i at det også kører på mobile enheder. De simple målinger jeg har foretaget viser imidlertidig at det er alt andet end tilfredsstillende hastigheder, der præsteres. Der findes dygtige udviklere og interaktive designere, der kan presse de vildeste ting ud af JavaScript og leverer imponerende eksempler på deres kunnen, men der er altså også de andre – dem der er mindre rutineret og leverer meget tung kode. Deres uvidenhed og manglende muligheder for at teste på alle de forskellige mobile enheder der findes, gør at de nok tager deres udvikling for givet eller i værste tilfælde helt glemmer at der findes smartphones. Og hvis de husker at de findes, så husker de måske ikke at folk har givet flere tusinde kroner for dem, og måske stadig ikke kan forsvare at der skal købes ny, lige med det første.

De store sites kommer ganske givet ikke i problemer, men mindre og mellemstore virksomheder, har måske ikke ressourcer til at optimere eller lave deciderede mobiloptimerede sites. Mange vil sidde med en holdning at folk jo kan opdatere deres telefon med en nyere model, eller leve med at det jo trods alt går lidt langsommere på små enheder.

Tilbage til overfladen

Det er selvfølgelig en pessimistisk tankegang, og den prøver også at ridse noget op, der skal gøres en indsats for at undgå. Jeg er af den overbevisning at vi er nød til at skrue vores tanker tilbage til tiden før iPhone – selv om vi udvikler til iPhone. Vi skal have fornemmelsen af at skære billeder til op optimere kode, når vi designere websites. Mine fornemmelser er at der ikke er noget negativt at sige om selve HTML5, CSS3 og jQuery mobile. De kører fantastisk på de fleste modeller jeg har testet. Anderledes anstrengt forhold har jeg til canvas elementet og JavaScripts arbejde på den. Det kan så nemt gå galt med koden, der gør de kreative idéer uløselige på grund af dårlig performance på mobile enheder.

I fremtiden bør vi overveje om indhold er relevant at vise på en tablet eller smartphone. Vi skal søge lidt væk  fra at alt fra desktop skal med, eller at folk har mulighed for at prøve kræfter med de interaktive og programmeringstunge dele af sitet. Styrkeforholdet er skiftet igen, efterhånden som browserforskelle udviskes, og udviklerplatformen (Mac og Windows) er overbefolket af Quad Core processorer og vilde grafikkort.

De nye muligheder med Canvas er mange gange de hurtige maskiner forundt. For kort tid siden var alle øjne på mobilerne. Det er de på mange punkter stadig, men grænsesøgning og de ekstreme eksempler er lukket land for mange mobiler – det bør man huske når eksemplerne rykker fra laboratoriet og ind i produktionshallerne.


HTML5 canvas with JavaScript and Flash Player performance

This post is an examination of the performance provided by JavaScript and the canvas HTML element, and its role on mobile platforms in the future. The inspiration for this post came when I stumpled on Water Ripple Canvas by Almer Thies. It was running without problems (with Canvas: 20fps and Water: 30 fps) on my computer but was frighteningly slow with a max of 0.5 fps on my iPhone 4 (yep. A half frame per second!). I therefore found it relevant to produce a comparable piece of code that could run on the canvas element and easily port to Flash, so I could get an idea of how well each technology performed.
It is not a secret that I’m fond of the Adobe Flash Player, and have always believed that Apples excommunication of the player due performance issues had no standing ground, in light of the present alternatives. But HTML5 is a promising technology, that takes the job as website maker seriously again, and that may result in Flash being able to focus on it plug-in nature again, and help lift sites up above the tomorrows standard sites. The most important topic to discuss is: what should happen when our mobile visits a website in the month/years to come. Not distinguishing  between mobile and desktop would lead to sluggish performance on mobiles when canvas gets integrated in eager designers creative solutions – a future that I predict as the “big dip”, in the worst cases.

Study 1

The test case is the famous snowflake that are loved or hated by everyone. The effect is exclusively produced by code and can be scaled easily to increase the load on the processor. I found an example at http://blog.webreakstuff.com/2010/11/building-a-canvas-snowglobe/ by Pedro Freitas. The code can be found on GitHub via https://gist.github.com/716215. I would also use an FPS counter, which could easily be ported to ActionScript and chose snippet from http://stackoverflow.com/questions/4787431/check-fps-in-js
I need it to produce a working example of the FPS counter that can be found at http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowcanvas.html. I have come to the following data (max is set to 100 FPS):
  • Desktop PC: 99.9 FPS (Firefox)
  • MacBook Pro: 97 - 98 FPS (Safari)
  • iPad (iOS 4.3): 19 - 20 FPS (updated 17/3 – 2011)
  • HTC Desire HD (2.2): 15.5 - 16.5 FPS
  • Inspire 4G (2.3): ~ 14 FPS (updated 17/3 – 2011)
  • HTC Desire (2.2): 14.4 - 14.7 FPS
  • iPad 1 (iOS 4.3): 13 – 13.5 FPS (updated 17/3 – 2011)
  • iPad 1 (iOS 4.2): 12.4 - 13.3 FPS
  • iPhone 4 (iOS 4.3): 9.9 - 10.5 FPS (updated 17/3 – 2011)
  • iPhone 4 (iOS 4.2): 9.9 - 10.3 FPS
  • iPhone 3GS (iOS 4.2): 9.9 - 10.3 FPS
  • HTC Legend: 7.5 - 8.9 FPS
Thanks to @seb_ly and @leebrimelow for additional test results
When I dropped the restriction the PC actually easily spun on over 200 FPS, but the intention here is not to benchmark in the high end, but find a relationship in the “low end” and a relative measurement to a standard machine. PC as well as Mac differ so much on hardware as well as range of browsers, it will not contribute anything positive to uncover all facets.

Conclusion 1

It is evident that both computers frame rates hits the ceiling. The portable Mac has thrown a frame or two in the test, but will probably do 100 FPS in a another run, or with another browser. Of course it cannot run from a Quadro graphics card, but it’s clearly capable of running the test. iOS machines (iPad 1, iPhone 3GS and iPhone 4) has a hard time, to produce frames for the canvas element. On average, they just over 10 FPS.
Desire HD is a bit higher. Not much, but still enough that it should be designated as a better settlement. Lowest is the HTC Legend, with around 8 fps.

Study 2

The second test was made to compare performance between javascripts work on the canvas, and Flash Player’s work with the BitmapData class. The technique used for both are very similar and it will give the best basis for comparison, and minimal editing of the code. You can see an example at http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.html
The following changes have been made from the original code:
  • Snow flakes was made as a separate class (Flake.as)
  • Updated variables, etc so they are strictly typed
  • Minor changes in variable names
  • Used Flash Player’s flash.sensors.Accelerometer to handle motion

Flake.as

 

package 
{ 
import flash.display.Sprite; 
import flash.display.BitmapData; 

public class Flake extends Sprite 
{ 
private var canvasWidth; 
private var canvasHeight; 
private var speed: Number; 
private var alpha: Number; 
private var size: Number; 
private var amp: Number; 
private var shift: Number; 
private var range: Number; 

public function Flake (w, h, a, s) 
{ 
this.canvasWidth = w; 
this.canvasHeight = h; 
this.x = 200; 
this.y = Math.random () * -1 * h; 
this.alfa = Math.random () * 0.5 + a; 
this.speed = Math.random (); 
this.size = s - this.speed - this.alfa; 
this.amp = Math.random () * 2; 
this.shift = Math.random () * 25 + 25; 
if (Math.random ()> 0.5) 
{ 
this.shift *= -1; 
} 
this.drift = Math.random () - 0.5; 
draw (); 
} 
public function draw (canvas: BitmapData = null): void 
{ 
this.graphics.beginFill (0xFFFFFF, this.alfa); 
this.graphics.drawCircle (0.0, this.size); 
this.graphics.endFill (); 
} 
public function move (f, wind): void 
{ 
this.y + = this.speed; 
this.x + = Math.cos (f / this.shift) * this.amp + + this.drift wind; 
if (this.y> this.canvasHeight) 
{ 
this.restart (); 
} 
} 
public function restart (): void 
{ 
this.y = -20; 
this.shift = Math.random () * 25 + 25; 
this.x = 200; 
} 
} 
}

 

 

MainApp.as

package
{ 
import flash.display.Sprite; 
import flash.display.Bitmap; 
import flash.display.BitmapData; 
import flash.utils.Timer; 
import flash.events.TimerEvent; 
import flash.geom.Rectangle; 
import flash.geom.Matrix; 
import flashx.textLayout.elements.InlineGraphicElement; 
import flash.sensors.Accelerometer; 
import flash.events.AccelerometerEvent; 
import flash.text.TextField; 

public class MainApp extends Sprite 
{ 
private var bgflakes: Array = new Array (); 
private var fgflakes: Array = new Array (); 
private var bgFlakeCount: int = 200; 
private var fgFlakeCount: int = 50; 
private var frame count: int = 0; 
private var wind: int = 0; 
private var dWidth: int; 
private var dHeight: int; 
private var orientX: int = 1; 

private var bgBitmapData: BitmapData; 
private var bgCanvas: Bitmap; 
private var fgBitmapData: BitmapData; 
private var fgCanvas: Bitmap; 
private var timer: Timer; 
private var orientation: Boolean = false; 
private var myAcc: Accelerometer; 

private var filter Strength: int = 20; 
private var frame hours: int = 0; 
private var loading loop: Date = new Date (); 
private var this loop: Date = new Date (); 

private var fps: TextField; 

public function MainApp () 
{ 
init (); 
} 

private function init () 
{ 
dWidth = this.stage.stageWidth; 
dHeight = this.stage.stageHeight; 
bgBitmapData = new BitmapData (dWidth, dHeight, false, 0x000000); 
bgCanvas = new Bitmap (bgBitmapData); 
fgBitmapData = new BitmapData (dWidth, dHeight, true, 0xFF0000); 
fgCanvas = new Bitmap (fgBitmapData); 
addChild (bgCanvas); 
addChild (fgCanvas); 

fps = new TextField (); 
addChild (fps); 
fps.textColor = 0xFFFFFF; 

was i = 0; 
for (i = 0; i { 
bgflakes.push (New Flake (bgCanvas.width, bgCanvas.height, 0,3)); 
} 
for (i = 0; i { 
fgflakes.push (New Flake (fgCanvas.width, fgCanvas.height, 0.2,4)); 
} 
hours = new Timer (10); 
timer.addEventListener (TimerEvent.TIMER, draw); 
timer.start (); 

if (Accelerometer.isSupported) 
{ 
orientation = true; 
myAcc = new Accelerometer (); 
myAcc.addEventListener (AccelerometerEvent.UPDATE, onAccUpdate); 
} 
} 

private function onAccUpdate (e: AccelerometerEvent): void 
{ 
orientX = e.accelerationX; 
} 

private function setWind () 
{ 
if (! orientation) 
{ 
was mx: Number = mouseX - dWidth / 2; 
wind = (mx / dWidth) * 3; 
} 
lodging 
{ 
Wind = Number (orientX) * 3; 
} 
if (! wind) 
{ 
wind = 0; 
} 
} 

private function draw (e: Event hours) 
{ 
frame count + = 1; 

bgBitmapData.fillRect (new Rectangle (0.0, dWidth, dHeight), 0x000000); 
fgBitmapData = new BitmapData (dWidth, dHeight, true, 0xFF0000); 
setWind (); 
was: int = 0; 
for (i = 0; i { 
bgflakes [i]. move (frame count, wind); 

bgBitmapData.draw (bgflakes [i], new Matrix (1,0,0,1, bgflakes [i]. x, bgflakes [i]. y)); 
} 
for (i = 0; i { 
fgflakes [i]. move (frame count, wind); 

fgBitmapData.draw (bgflakes [i]); 
} 

was this frame hours: int = (Number (this loop = new Date ())) - Number (last loop); 
Frame hour + = (this frame - time frame hours) / filter strength; 
load loop = this loop; 
fps.text = (1000/frameTime). toFixed (1) + "fps"; 
} 
} 
}

 

Comments on Code
I have kept the draw () inside the Flake class and draw the flakes with graphics.drawCircle () to keep the code across the examples as similar as possible. The transfer of values on canvas size, etc. are also retained in the Flash version is also preserved. Finally, I used Bitmap () and BitmapData () to simulate the properties used on the canvas element.

Results 2

With mobile units, that is capable of running Flash Player 10.1 and canvas, I try to measure them against each other. Not as a battle, favoring one technology, for the future (I think) belongs to them both. It’s more an attempt to find out how bad Flash performs and supporters of the canvas as a “Flash Killer” has some back support. I’ll update as I stumple on different phones/tablets on my way:
  • Dersire HD (2.2): Canvas ~ 16.5 FPS and Flash 10.1 ~ 24.2 FPS
  • Inspire 4G (2.3): Canvas ~ 14 FPS and Flash 10.1 ~ 22 FPS (updated 17/3 – 2011)
  • HTC Desire (2.2): Canvas ~ 14.5 FPS and Flash 10.1 21.7 to 23.5 FPS
You are welcome to submit own measurements

Conclusion

I get a relatively higher frame rate when running the test in Flash Player on Android than if I the canvas version. I wasn’t able to turn the relationship between the numbers on my phone, not even leveling the difference in frame rate. I therefore think that the user will have a better experience of this experiment in a flash player, than with a canvas version. It is important to remember that the canvas element’s ability to deliver, do not need to inflict on the general view on HTML5 and CSS3. My feeling is that CSS3 has a fairly good performance on the mobile devices, perhaps because of their predictable nature, but I haven’t investigated that topic yet.
Finally, I have not taken installed software on the devices into account. It may be relevant in a recount to look at parameters such as:
  • How long the phone has been switched on.
  • Is it connected to the charger.
  • Programs running in the background.
  • Video documentation of test
My point here is to get some numbers up in the air, and a comparison of material playd on mobile devices. Please reply with the results of your own measurements for computer, tablet and mobile.
Links to tests:
Links to documents

HTML5 canvas med JavaScript og Flash Player performance

Dette indlæg er en undersøgelse af den performance som præsteres af henholdsvis JavaScript og Canvas elementet og dets rolle på mobile platforme i fremtiden. Inspirationen fik jeg da jeg kom forbi Almer Thies Water Ripple Canvas der kørte uden problemer (med Canvas: 20fps og Water:30 fps) på min computer men skræmte mig fra vid og sans med et maks på 0.5 fps på min iPhone (yep. En halv frame i sekundet!!). Jeg fik derfor en idé om at finde et sammenligneligt stykke kode, der kunne afvikles fra canvas og nemt porteres til Flash, så jeg kunne danne mig et overblik over hvor godt de hver i sær præsterede.
Selv er jeg tilhænger af Adobe Flash Player og har altid ment at iOS bandlysning af den på grund af performance ikke havde nogen gang på jord, set i lyset af alternativerne. At vi så grundlæggende skal tage os en grundig snak om, hvad der skal ske, når vores mobile enheder besøger en hjemmeside i årene der kommer, er en helt anden snak – en fremtid, som jeg spår som “det store dyk”, i værste tilfælde.

Forsøg 1

Valget faldt på de berømte snefnug, som er elsket/hadet af alle. Effekten bliver udelukkende produceret med kode, og kan skaleres nemt for at øge belastningen. Jeg fandt et eksempel på http://blog.webreakstuff.com/2010/11/building-a-canvas-snowglobe/ af Pedro Freitas. Koden kan findes på Github via https://gist.github.com/716215. Jeg skulle også bruge en FPS-counter, der nemt kunne porteres til ActionScript og valget faldt på kodestumpen fra http://stackoverflow.com/questions/4787431/check-fps-in-js
Jeg har brug det til at producere et virkende eksempel med FPS-counter, der kan findes på http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowcanvas.html. Jeg er kommet frem til følgende data (max er sat til 100 FPS):
  • Desktop PC: 99.9 FPS (Firefox)
  • MacBook Pro: 97 - 98 FPS (Safari)
  • iPad (iOS 4.3): 19 - 20 FPS (opdateret 17/3 – 2011)
  • HTC Desire HD (2.2): 15.5 - 16.5 FPS
  • Inspire 4G (2.3): ~ 14 FPS (opdateret 17/3 – 2011)
  • HTC Desire (2.2): 14.4 - 14.7 FPS
  • iPad 1 (iOS 4.3): 13 – 13.5 FPS (opdateret 17/3 – 2011)
  • iPad 1 (iOS 4.2): 12.4 - 13.3 FPS
  • iPhone 4 (iOS 4.3): 9.9 - 10.5 FPS (opdateret 17/3 – 2011)
  • iPhone 4 (iOS 4.2): 9.9 - 10.3 FPS
  • iPhone 3GS (iOS 4.2): 9.9 - 10.3 FPS
  • HTC Legend: 7.5 - 8.9 FPS
Tak til @seb_ly og @leebrimelow for yderligere testresultater
Jeg droppede begrænsningen og så at PC’eren faktisk nemt snurrede den over 200 FPS, men meningen her er ikke at benchmarke i den høje ende, men finde et forhold i “den lave ende” og en relativ måling til en standard maskine. PC såvel som Mac varierer så meget på hardware samt udvalg af browsere, at det ikke vil bidrage til noget positivt at afdække alle facetter.

Konklusion

  • Det er klart at fornemme at begge computere rammer toppen. Den bærbare Mac har smidt en frame eller to i testen, men vil sikkert ramme 100 FPS i en anden. Selvfølgelig kan den ikke løbe fra et Quadro grafikkort, men klart er det at der er rigelig overskud til at løse opgaven.
  • iOS maskinerne (iPad 1 og iPhone 4) har en hård tid, med at producere frames til canvas elementet. I gennemsnit ligger de på lidt over 10 FPS.
  • Desire HD ligger en smule højere. Ikke meget, men alligevel nok til at det må betegnes som en bedre afvikling.

Forsøg 2

Forsøg nummer to var lavet for at sammenligne performance mellem JavaScripts arbejde på canvas, samt Flash Playerens arbejde med BitmapData klassen. Teknikken der bruges til begge er meget ens, og det vil give det bedste sammenligningsgrundlag, og mindst mulig redigering i koden. Du kan se et eksempel på http://eksempler.hjaelpmignu.dk/flash/actionscript/snowflake/snowFLA.html
Følgende ændringer er blevet foretaget fra originalkoden:
  • Snefnug lavet som en selvstændig klasse (Flake.as)
  • Har opdateret variabler osv så de er strict typed
  • Mindre ændringer i variabel navne
  • Brugt Flash Playerens flash.sensors.Accelerometer til at håndtere bevægelse
Flake.as

package
{
import flash.display.Sprite;
import flash.display.BitmapData;

public class Flake extends Sprite
{
private var canvasWidth;
private var canvasHeight;
private var speed:Number;
private var alfa:Number;
private var size:Number;
private var amp:Number;
private var shift:Number;
private var drift:Number;

public function Flake(w,h,a,s)
{
this.canvasWidth = w;
this.canvasHeight = h;
this.x = 200;
this.y = Math.random() * -1 * h;
this.alfa = Math.random() * 0.5 + a;
this.speed = Math.random();
this.size = s - this.speed - this.alfa;
this.amp = Math.random() * 2;
this.shift = Math.random() * 25 + 25;
if (Math.random() > 0.5)
{
this.shift *=  -1;
}
this.drift = Math.random() - 0.5;
draw();
}
public function draw(canvas:BitmapData = null):void
{
this.graphics.beginFill(0xFFFFFF,this.alfa);
this.graphics.drawCircle(0,0,this.size);
this.graphics.endFill();
}
public function move(f,wind):void
{
this.y +=  this.speed;
this.x +=  Math.cos(f / this.shift) * this.amp + this.drift + wind;
if (this.y > this.canvasHeight)
{
this.restart();
}
}
public function restart():void
{
this.y = -20;
this.shift = Math.random() * 25 + 25;
this.x = 200;
}
}
}

 

MainApp.as
 

package
{
import flash.display.Sprite;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.utils.Timer;
import flash.events.TimerEvent;
import flash.geom.Rectangle;
import flash.geom.Matrix;
import flashx.textLayout.elements.InlineGraphicElement;
import flash.sensors.Accelerometer;
import flash.events.AccelerometerEvent;
import flash.text.TextField;

public class MainApp extends Sprite
{
private var bgflakes:Array = new Array();
private var fgflakes:Array = new Array();
private var bgFlakeCount:int = 200;
private var fgFlakeCount:int = 50;
private var frameCount:int = 0;
private var wind:int = 0;
private var dWidth:int;
private var dHeight:int;
private var orientX:int = 1;

private var bgBitmapData:BitmapData;
private var bgCanvas:Bitmap;
private var fgBitmapData:BitmapData;
private var fgCanvas:Bitmap;
private var timer:Timer;
private var orientation:Boolean = false;
private var myAcc:Accelerometer;

private var filterStrength:int = 20;
private var frameTime:int = 0;
private var lastLoop:Date = new Date();
private var thisLoop:Date = new Date();

private var fps:TextField;

public function MainApp()
{
init();
}

private function init()
{
dWidth = this.stage.stageWidth;
dHeight = this.stage.stageHeight;
bgBitmapData = new BitmapData(dWidth,dHeight,false,0x000000);
bgCanvas = new Bitmap(bgBitmapData);
fgBitmapData = new BitmapData(dWidth,dHeight,true,0xFF0000);
fgCanvas = new Bitmap(fgBitmapData);
addChild(bgCanvas);
addChild(fgCanvas);

fps = new TextField();
addChild(fps);
fps.textColor = 0xFFFFFF;

var i = 0;
for (i=0; i 			{
bgflakes.push(new Flake(bgCanvas.width, bgCanvas.height,0,3));
}
for (i=0; i 			{
fgflakes.push(new Flake(fgCanvas.width, fgCanvas.height,0.2,4));
}
timer = new Timer(10);
timer.addEventListener(TimerEvent.TIMER, draw);
timer.start();

if (Accelerometer.isSupported)
{
orientation = true;
myAcc = new Accelerometer();
myAcc.addEventListener(AccelerometerEvent.UPDATE, onAccUpdate);
}
}

private function onAccUpdate(e:AccelerometerEvent):void
{
orientX = e.accelerationX;
}

private function setWind()
{
if (! orientation)
{
var mx:Number = mouseX - dWidth / 2;
wind = (mx/dWidth)*3;
}
else
{
wind = Number(orientX) * 3;
}
if (! wind)
{
wind = 0;
}
}

private function draw(e:TimerEvent)
{
frameCount +=  1;

bgBitmapData.fillRect(new Rectangle(0,0,dWidth, dHeight),0x000000);
fgBitmapData = new BitmapData(dWidth,dHeight,true,0xFF0000);
setWind();
var i:int = 0;
for (i=0; i 			{
bgflakes[i].move(frameCount, wind);

bgBitmapData.draw(bgflakes[i], new Matrix(1,0,0,1,bgflakes[i].x, bgflakes[i].y));
}
for (i=0; i 			{
fgflakes[i].move(frameCount, wind);

fgBitmapData.draw(bgflakes[i]);
}

var thisFrameTime:int = (Number(thisLoop=new Date())) - Number(lastLoop);
frameTime+= (thisFrameTime - frameTime) / filterStrength;
lastLoop = thisLoop;
fps.text = (1000/frameTime).toFixed(1) + " fps";
}
}
}

 

Kommentarer til koden
Jeg har beholdt draw() inde i Flake klassen og tegner den fysisk op med graphics.drawCircle() for at beholde koden på tværs af eksemplerne. Overførsel af værdier om canvas-størrelse osv. er også bevaret i Flash eksemplet er også bevaret. Endelig er der brugt Bitmap() og BitmapData() til at simulere de egenskaber som bruges på canvas elementet.

Resultat 2

På modeller, hvor der både kan køres Flash Player 10.1 og canvas vil jeg prøve at teste dem op mod hinanden. Ikke så meget en kamp mellem det ene og det andet, for fremtiden (tror jeg) tilhører dem begge, men mere et forsøg på at finde ud af, hvor dårlig Flash præsterer og om tilhængere af canvas, som “Flash Killer” har noget at have det i. Jeg vil opdatere efterhånden som jeg rammer flere forskellige telefoner på min vej:
  • Dersire HD (2.2): Canvas ~ 16.5 FPS og Flash 10.1 ~ 24.2 FPS
  • Inspire 4G (2.3): Canvas ~ 14 FPS og Flash 10.1 ~ 14 FPS (opdateret 17/3 – 2011)
  • HTC Desire (2.2): Canvas ~ 14.5 FPS og Flash 10.1 21.7 to 23.5 FPS
I er velkommen til at indsende oprigtige målinger

Konklusion

Jeg ser en relativ højere frame rate når jeg afvikler i Flash Player på Android, end hvis jeg udfører tilsvarende med canvas elementet. Det er ikke lykkedes mig at vende forholdet mellem tallene på min telefon, end ikke få dem til at nærme sig hinanden, mærkbart. Jeg vil derfor mene at brugeren vil have en bedre oplevelse af dette eksperiment i en Flash Player, end ved en canvas-løsning. Det er vigtigt at huske på, at canvas elementets evne til at præstere, ikke behøver at gå ud over den generelle opfattelse af HTML5 og CSS3. Min fornemmelse er, at CSS3 har en ok afvikling på de mobile enheder, måske på grund af deres forudsigelige natur, men det har jeg stadig tilbage at undersøge.
Endelig har jeg ikke forholdt mig til, hvad der er installeret på enhederne. Det kan være relevant i en fintælling at se på parametre som:
  • Hvor lang tid telefonen har været tændt.
  • Er den tilsluttet oplader.
  • Kører der programmer i baggrunden.
  • Videodokumentation af test
Mit ønske her er at få nogle tal i luften, og et forhold til den relativt ringe afvikling af materiale på mobile enheder.
Meld gerne tilbage med resultater af jeres egne målinger på computer, tablet og mobil.
Links til tests:
Links til dokumenter

Photoshop begynder at opføre sig mærkeligt efter opdatering af Mac OSX

Hvis din udgave af Photoshop begynder at opføre sig underligt på Mac, kan det være fordi systemet er blevet opdateret til Mac OS 10.6.5 eller Mac OS 10.6.6.
I følge Adobes egen Knowledge base (http://kb2.adobe.com/cps/881/cpsid_88159.html) kan de kun opfordre til at systemet bliver på version 10.6.4, indtil en løsning er fundet, men i praksis er det jo nok ikke muligt.

En udvikler (Jesper Storm Bache) blandede sig i en diskussion på Adobe Forums (http://forums.adobe.com/thread/752602) og er kommet med et hack, der løser problematikken indtil der kommer en permanent løsning fra Apple.

Vær lige opmærksom på at denne hack går ind og retter i selve systemet, og der er ingen garanti for at det ikke har indvirkning på andre applikationers måde at fungere på … er dog ikke bekendt med nogle bivirkninger.

Du kan hente hack’en på http://www.bache.name/download/osx/10_6_5%20keyboard%20hack.dmg


Pappa’s got a brand new badge (Adobe Community Champion 2011)

Så kom listen med de udvalgte Community Champions for 2011, og jeg er glad for at se at jeg har fået lov til at bestride jobbet (igen) i år. Det bliver et rigtigt spændende år for internetteknologier og software til design og udvikling på diverse platforme, og jeg glæder mig til at sprede information om Flash, HTML5, Adobe, Photoshop, mobile, interaktivitet, Illustrator osv. osv. til alle der gider at høre nyt fra den verden.

Hvad er en Community Champion?

Der er lidt meget glasur på titlen, og det lyder nok voldsommere end det er. Adobes egen beskrivelse, nagler de vigtigste pointer meget godt og betyder i al sin enkelthed at jeg skal blive ved med at gøre som jeg altid har gjort … snakke løs :-) Hvad enten der er tale om møder i AUGOD (Den danske Adobe Brugergruppe), diverse events og produktlanceringer til folks sporadiske spørgsmål og lyst til at få opklaret (eller høre min version af) interaktive platformes mysterier og kringelkroge.

Så er du vel en rigtig Adobe lover?

det kan man da godt kalde mig. Men det er jeg kun fordi jeg elsker de værktøjer der er med til at skabe de flotteste og mest innovative løsninger online, såvel som offline. Kærligheden strækker sig over alle produkterne og de muligheder de giver designere, men min kærlighed ligger også hos andre produkter fra andre udbydere, samt åbne standarder som HTML5. En stor del af mit virke i 2011 (under denne titel) vil nok være at overbevise folk om at Flash/HTML5 problematikken ikke er en enten-eller løsning, men en både-og, med forskellige teknologier til at løse forskellige typer af opgaver.

Endelig vil noget at tiden blive brugt på http://www.hjaelpmignu.dk/ hvor du kan få svar på de spørgsmål du end måtte have til programmer og teknologier forbundet med Creative Suite. Fyr løs, og svar eventuelt på andres problemer, hvis du har en løsning.

På gensyn derude

Dette indlæg er egentlig bare et heads up, på at jeg stadig er på, og I er mere end velkommen til at kontakte mig her, på www.hjaelpmignu.dk, eller følge mig på twitter (@ockley), så skal jeg se hvad jeg kan gøre for dig :-)

Med venlig hilsen

Karsten “ockley” Vestergaard