I don't like computers.

Mac vs PC

This is just to good to miss on a bloc called “I don’t like computers.”:

ActionScript/Flex Dependency Injection performance

I’m currently sneaking around the dependency injection (DI) frameworks Dawn, Swiz and Parsley. None of which I have ever used in production, so take my judgment with care. At first look, the use of Dawn is simplest and most concise and somewhat similar to Google’s Guice which I like. In Swiz, I don’t like the global state used in event handling. Parsley is well documented but a framework that is configurable by XML makes me very suspicious.

Tests

DI depends on reflection on classes which is mainly done with describeType() in Flash. I had in mind that it was a very slow function, but I didn’t know for sure. So I wrote some code to estimate the runtime performance of DI frameworks:

Find metatdata tag [Inject] in different classes:
5050 μs for UIComponent
5150 μs for PersonDetails
700 μs for PersonDetails with DescribeTypeCache
30 μs for SimplestClass
360 μs for describeType XML of UIComponent

2 us to dispatch and handle an event

0.2 μs to call getQualifiedClassName(UIComponent)
1.6 μs to call getDefinitionByName(UIComponent)

0.3 μs to call uiComponent['drawFocus']
0.2 μs to call uiComponent.hasOwnProperty('maxHeight')
0.7 μs to call uiComponent['maxHeight']

9 μs to call Log.getLogger('mx.core.UIComponent')
12 μs to call CreateLogger.withClassNameOf(VBox)

μs = microseconds

You can evaluate the Flash Player performance yourself with the app. The code is available with a right click on the app.

Results

describeType() is really slow. It takes more than 5ms on UIComponent. What surprised me positively is the speed of getQualifiedClassName(). I flipped all logger creation to using getQualifiedClassName() with the helper class CreateLogger.as since.

Conclusion

Dependency injection frameworks make only sense in big projects. Let’s assume a project with 200 different classes that have injected objects, the start up time will increase by 1 second. Knowing that Flex applications don’t fire up quickly, 1 second is surely too long. For BlocStac, I will use DI only in side projects and hope that Flash Player offers faster reflection functions soon.

Flex component EditImage rewritten

Past releases of the free EditImage component have seen some interest. So I thought, I could also share the new version which is written from scratch. EditImage suits the needs of the BlocStac wiki, but maybe you can tweak it for your own purpose. Just to make it clear, EditImage is for Flex developers.

The current features are:

  • scale
  • crop
  • rotate
  • undo/redo
  • zooming (not scaling) and panning the image
  • zoom the image to maximum allowed width
  • 3 states: zoomable, editable and only readable
  • import/export

Demo

As before, the source code is under the liberal BSD license and you can find it on Google code. As we use this code internally, expect changes in the source. However, note that we will not tag any release in mercurial. EditImage requires Flex 4 and Flash Player 10.

Have fun using it,

Marc

Stand up AGAINST Generics/Concurency in Flash Player

I’ve just read Joa Ebert’s excellent post “This is an outrage”  about the Flash platform. I totally agree on the big picture but don’t like some language proposals. As my tiny little contribution, I’d like to dissect and reassemble some often heard wishes for the ActionScript language.

Reading about generics and concurrency in Flash Player makes me nervous. I have read many wishes about those two features but never found a very precise description of what they really want. I fear that many think of language features found  in C++, C# or Java. The problem I have with those languages is that the language complexity reduces massively developer efficiency and effectiveness. Why do so many developers flee to Ruby, Python, Scala  or F#? How can ThoughtWorks state that they are  roughly two times faster in developing with a language that has no generics but the feature is still high on the wish list for ActionScript?

Generics

Please correct me if I’m wrong but you could not do more with generics in ActionScript. So we are talking about a usability feature for the developer, right? Instead of endless castings and writing tests, the compiler could do some of this work. But do generics really make you write and much more importantly read ActionScript code faster? If I think of Java 1.6 generics, my answer is certainly no and that’s the reasons why I’m against generics as known in Java.

However, I see some areas where type safety increases developer productivity. Vector is a great example and like Joa, I’d like to see some more native collections in Flash Player that use generics. But besides those exceptions, I don’t need generics.

Concurrency

I see two feature requests in concurrency: The first one is run time performance. The number of CPU cores is going to increase steadily and developers can only leverage several cores in PixelBender in Flash Player 10.  I think of PixelBender as a machine that launches as many thread as there are pixels in the output. Everything is finally joined when jumping back to ActionScript. So basically, we have already concurrency for a dedicated purpose. Sure, Flash Player needs to be able to leverage several cores (as it is already today) but I’d prefer if the VM could take care of concurrency. While writing code, I don’t want to think in CPU cores but in my business domain. Though I must admit that I don’t know anything about the feasibility of such an approach.

The second feature in concurrency are parallel tasks in an application. For example, saving data to a server and updating the display could run in parallel. The developer needs to control these parallel tasks. I know Java reasonably well and I fought trough Java Concurrency in Practice which I recommend. However, if it takes a book of 400 pages to know the basics of concurrency, the feature is never worth the pain of learning it. I would argue that concurrency introduces a level of complexity that nobody can master in a mid-sized project anymore. You just happen to fix known issues but you can not validate it. Testing concurrency is not even in its infancy.

That’s the reason why I plea for a much simpler solution compared to the implementation in Java. Maybe having a fixed number of e.g. 4 threads makes it a lot easier. Or maybe making all accesses synchronized per default and defining the exceptions is something to consider; I don’t know. I don’t pretend to know a great solution, I only know that I don’t want any solution I know today.

Bonus feature: Overloading

While allowing to apply all standard namespaces to constructors reduces complexity in ActionScript, overloading certainly adds more complexity. What’s the benefit instead of handling the different types in the constructor or method itself like in e.g. Python? If we had powerful pattern matchers like Scala has, I could easily live without overloading. Pattern matcher could also play a major role in solving “generics task”.

About Complexity

I find the comment of Lee Brimelow brings it to the point: “…there is also a huge segment of the community who is still really struggling with moving to AS3 as it is now“. For example, I would argue that probably half of all Flex developers are not aware that they create a potential memory leak when referencing objects in an array. They don’t care and they shouldn’t. Adding those features mentioned above will make even more people write buggy code.

Better and faster results

What makes me faster in reading and writing is rather for example type inference and tweaking the functional programming approaches. Which example do you understand faster?


//ActionScript 3
var vw:Car = new Car()
var cars:Vector.<Car> = new Vector.<Car>
cars.push(vw)
readyToDrive = cars.every(function(car:*, index:int, arr:Array):Boolean {
return Car(car).hasEnoughOil
})

or

//ActionScript 2010
vw = new Car()
cars = new Vector.<Car>
cars.push(vw)
readyToDrive = cars.every(return car.hasEnoughOil)

Some more spontaneous thoughts for language improvements:

  • Like in Dictionary, allow weak references in many places.
  • I’m not sure about adding [Mixin]. Haven’t thought through it yet.
  • {} should become in most situations optional as the semicolon is today.
  • If you care about raw performance, use Alchemy, write bytecode with the help of the excellent haxe project, launch a job for PixelBender or pray that the compiler gets more love by Adobe. It’s also clear that AVM2 needs to speed up as well. But don’t clutter ActionScript with pure performance features. After all, ActionScript is just a layer above byte code that should increase developer productivity (performance improvements from the compiler seem too far away).
  • (Sorry, this is my personal, pretty much hopeless fight :) What the community could already do today is dropping this silly ;;;;;;;;;; at the end of each line. It’s just visual clutter and about as useful as adding “//end of line” at each line end.

Finally

My point is that ActionScript should not blindly chase any other language. Adobe should only add language features if they either increase developer productivity or enable new possibilities for the Flash Platform including run time performance. And of course, only after a thorough discussion in the community before implementing.

But at the end of the day, I preferred to use Python or Ruby to program Flash and leave the stalled ECMA standard behind. Hey, maybe Adobe pops up with an equally solid APython or ARuby compiler at MAX?

Mocking in Flex/ActionScript has arrived: mockito-flex

The announcement of Google Chrome OS is certainly a big bang in the IT world. However, this didn’t made my day but the public release of mockito-flex. It’s been quite painful to create mock objects up to now in Flex. mock-as3 was best until I read on InfoQ about mockito-flex. It’s based on asmock but the syntax feels very much like mockito for Java (which is in my opinion the best mock library in Java). The documentation is still sparse, so below are all the things I need to know:


given(mockie.foo(10)).willReturn("10")
given(mockie.foo(10)).willThrow(new Error("oups"))
given(mockie.foo()).will(new GenericAnswer(incrementCounter))
verify().that(array.push("1"))
verify().that(array.pop())
verify().that(mockie.baz(eq("one"), any()))
verify().that(mockie.baz(argThat(new GenericMatcher("two", contains)), eq(10)))
verify(never()).that(testClass.foo())
verify(times(3)).that(testClass.foo()) // atLeast(4), atLeastOnce(), once()

Amazon S3 + Flash crossdomain.xml + IE7 = Certifacte error

This is just an other story why I don’t like computers… When the Flash Player loads files from Amazon S3, it most likely crosses the domain border. This means that you have to put up yourself with Flash Player security. If you planned a new security concept for Flash Player and you want to make it as complex and convoluted as you could ever imagine and then, you power this by the factor of 10, you most likely come up with the current Flash Player security concept. Ok, if it hadn’t changed much over the years. But did you know that for example the allowed HTTP header changed in every release! I bet that there are no more than 10 people on the world that understand everything including the implications of the changes over the years.

Whatever, loading the crossdomain.xml from Amazon S3 does not fail because of Flash Player. That’s why loading the file works fine in Firefox but fails in Internet Explorer and Safari. The URL was something like https://images.example.org.s3.amazonaws.com/crossdomain.xml“. It turns out that Internet Explorer does not accept address with “.” for wildcard SSL certifactes like “*.s3.amazonaws.com”. So this story ends with the fact that you should only use bucket names without “.” like https://myimages.s3.amazonaws.com/crossdomain.xml“.

Multi-touch for Adobe Flex: Introduction in Hardware and Software


I’m convinced that keyboards and mice are going to be complemented with multi-touch screens in a staggering short period. This believe drives me to check the current state of the technology. I split the analysis into three areas: the hardware, the “software engine room” and “user gestures and applications”. Because we need a presentation wall at Faindu, I confine all aspects to large screen applications.

Generally, NUI Group is the hot spot. For diving into the technology, I also found the master thesis of Laurence Muller published this September quite useful.

Multi-touch Screens

All commercial hardware I found starts with a price tag of several 1’000 €. And until the 3D-camera sits in every laptop, we will need to settle for 2D surface interaction. There is a thread on NUIgroup that summarizes nicely the following four technologies. All four options are based on the same physical principle: finger tips or any other objects emit infrared (IR) light and are tracked by an IR-filtered camera. Those artifacts detected by an image processing algorithms are called “blobs“. The tracked object could actively emit light with an IR-LED but this required the user to wear gloves or something like a mini-torch. Because this is not geeky enough, all principles rely on reflecting IR-light on the object. So the real challenge is to illuminate several objects on the surface with evenly distributed intensity and indirection.

  • Diffused Illumination, DI: Several IR-lamps spot form the the back onto the surface.
  • Diffused Surface Illumination, DSI: Tim Roth introduced the DSI technology. Contrary to what the name implies, the setup is very similar to FTIR
  • Frustrated Total Internal Reflection, FTIR: While DSI relies on scattering the light in the material, FTIR uses optical reflections at the surface. Think of a thick telceom multimode fiber that is pressed into a flat form. A nice diagramm of Jeff Han’s former group, comprehensive instructions pdf by Harry van der Veen and other instructions by Christopher Jette.
  • Laser curtain or Laser Light Plane (LLP): One or several lasers span a curtain of light beams one millimeter in front of the screen. It was introduced by AlexP (update, newest post) on the NUIgroup forum and very well explained by Georg Kaindl.

If security issues can be resolved, LLP is my clear favorite.

Software on the “operating system” level

With “operating system” (OS) I mean the software that reads the data from the camera/s, processes it and sends the appropriate events in Actionscript. For the mouse or keyboard, this is on the operating system level, so I name it that way. TUIO is the standard for the communication between the multi-touch screen and applications.

I will explore tbeta and IDEO in more depth.

User gestures and Flex multi-touch applications

Apart from Bill Buxton’s page that also features an excellent overview, I could not find yet a lot of research about gestures. I want to know what people intuitively understand. Wiping horizontally with two fingers means to most users…? Tipping with three finger should do…? And the combination with two hands? Anyway, there are may applications around:

  • A blog of Harry van der Veen list three Actionscript applications developed by the NUIgroup.
  • Multi Touch Flickr Viewer lets you play with images.
  • mapstouch is an Air application and lets you navigate google maps. It is based on touchlib.
  • sparsh-ui is developed at the Iowa State University and features a gestures server. However, I could not find an Actionscript API.
  • There are no Flex components optimized for the multi-touch paradigm yet.
  • Website that collects videos of multi-touch applications.

Free Flex component: EditImage 0.3

There is an update of the component.

Demo / Source

Just an other alpha release of EditImage with some work in it:

  • Introduced interfaces for EditImage and the tools
  • Quite frequently, I use EditImage as an image display and non of the tools are needed. That is the reason I disabled all tools by default. They are not initialized until a tool is enabled.
  • Squashed some bugs like correct resizing of EditImage and positions of cursor
  • More refactoring and more API documentation
  • First unit tests added but many more needed
  • EditImage.swc, API documentation (/tmp/ant-doc/index.html) and link-report (/tmp/ant-swf/EditImageReport.html) included in EditImage.zip

What is still on the wish list?

  • As reported by Gireesh, when snap to top/left is disabled, the image can be move to any position on the screen.
  • More refactoring
  • Plug in new tools such as adding shapes, drawing with a pencil, adding text

Image editing component in Flex, Updated

There is an update of the component.

I found some more time to update EditImage. What’s now in the component?

  1. Cropping including constrains to size ratio and minimal height and width.
  2. Scaling including constrains to size ratio
  3. Rotating including constrains to steps. Rotating snaps to 0 degrees and a multiple of a defined value. It does not step through the angle with a fixed value disregarding of the starting angle like 3.456 degrees.
  4. Snap to the initial top left position.
  5. Serialize the sum of the transformations so you can store and retrieve the image edits.
  6. Reset the image to the original image dimension and orientation
  7. Reset image transformations to last set state.
  8. Source code is under the BSD license. Some icons are under LGPL.

What’s missing?

  1. No single test has been written.
  2. More documentation
  3. There are some low hanging fruits for performance improvements.
  4. Provide user feedback when hitting limits.
  5. Visual frames for picture

Have fun and report bugs.

Image editing component in Flex: EditImage

There is an update of the component.

I needed a simple image manipulation tool, similar to the one in Word. As I may want to use it in commercial products, the license is of importance. Here are the three options I found:

TransformManager

Jack Doyle has written the TransformManager component. On his blog, you also find some interesting image effects. Unfortunately, he excludes commercial use without explicit permission in his license.

ObjectHandles

Marc Hughes published ObjectHandles. It works just fine and it is under the MIT license. I might use it somewhen but the next component was just a better fit:

TransformTool

TransformTool has been hacked by Trevor McCauley and extended by Alessandro Crugnola. Trevor’s license is found in the About section and says All source files and downloads on this site are completely free to use any way you see fit for personal or commercial use. They are provided as is with no guarantee or warranty and are to be used at your own risk. I guess this allows the BSD license. Alessandro agreed by mail.

With about 80 private variables and a whopping 1’790 lines of code, TransformTool.as implements most of the functionality. I started refactoring this class at first but I haven’t finished it yet. Before we go into the details, here is the Demo and the Source see Update.

What’s new in EditImage?

  1. Cropping including constrains to size ratio
  2. Serialize the sum of the transformations so you can store and retrieve the image edits.
  3. Reset the image to the original image dimension and orientation
  4. Reset image transformations to last set state.
  5. If rotated, controls are rotated as well
  6. Rotate snaps to 0 degrees and a multiple of a defined value. It does not step through the angle with a fixed value disregarding of the starting angle like 3.456 degrees.
  7. Snap to the initial top left position.
  8. Refactored the different tools like scaling and cropping into their own package.
  9. Minimal height and width for cropping.
  10. Removed things I don’t need like registration point or skewing.
  11. It is under the BSD license.

What’s missing?

  1. This is a prototype, not a production-ready component!
  2. No single test has been written.
  3. Further clean up of code including documentation.
  4. I have not yet touched the cursors. They currently don’t work at all.
  5. Hunting some more bugs like reseting sometimes confuses the orientation of the controls.
  6. Provide user feedback when hitting limits.
Follow

Get every new post delivered to your Inbox.