"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Thursday, April 19, 2007

My RIA Is Dynamic -pause- Naught

Update: It's been a while but there are some corrections to this post.

  • The Flex API *does* support drawing on pixmaps so a MacPaint-like capability using this would be efficient.
  • All the controls can be created using the Flex 2 API fr ActionScript 3. There is just a minimal mxml wrapper required around the AS code. I can dig it out here if anyone wants to see it, but I'm too lazy at the moment.
End

I've been playing with Flex2 (I'd go all out with Apollo except it does not run on Linux yet and I don't have steady access to Windows XP or Mac OSX). I have some questions that I've posted to some lists, but maybe this blog can attract some feedback as well.

No Pixmaps?

First some general impressions: Flex could be so good, but I am not sure if it is. The basic display architecture is reasonably what I'd expect. I am kind of surprised there isn't a pixmap level drawing capability. (Or is there and I missed it?)

I created a simple paint program that frequently cycles through colors, transparency, and line width. After a minute of "painting" the retained structured graphics system bogs down and mouse events are handled fewer and farther between.

No Intelligent Redisplay?

Which leads to my next question: even if all graphics have to be retained as heavyweight objects, does the repaint really have to slow down mouse handling so dramatically, so soon? If my program is adding a new line just a few pixels long, shouldn't the damage and repaint occur in a small rectangle around that line? I cannot tell what's going on in the slowdown to be sure.

Since I have not found in the API any smart damage capability (e.g. "invalidate just this region for repainting") and only a display-wide "invalidate" then I might assume the entire display list is being repainted unnecessarily. Since the API does have a reasonable hit detection capability then I would expect that to be used to determine what to repaint, if the system had some understanding of where the damage is.

Controls Must Be Precompiled?

I would really like to generate some UI controls (e.g. labels and input controls) based on some data received from somewhere in the course of the application. I wrote a little app to try this out. Then I ran into an error at runtime when trying to add a label to a vbox... "TypeError: Error #1006: getInstance is not a function."

Apparently all the controls in mx.controls can *only* be created through XML and the Flex mxmlc compiler. Actually this is not strictly true since the -keep switch will keep around the generated ActionScript files. Em, not the most beautiful or concise code considering the app consists of a window, a vbox to stack controls, and one static text control.

All kinds of craps are generated that have *nothing* to do with the app. This can also be seen in the runtime behavior of the XML version of this simple thing. While the few small Flex apps I have written to date come up and are ready very quickly, the XML generated app comes up slowly. Looking at the code it is apparently due to all kinds of initialization of things the app will never use.

Ugh - factories initializing craps - a very heavyweight stretch of code. Generated from XML input run through a compiler. (Apparently in spite of ActionScript having reasonable support for XML *in* the language, mxml code can only be generated from a compiler written in Java that runs at build-time. (Or on a "server" if you want to call out to one that can run the compiler for you!)

The result is "rich" but not very "interactive" -- especially given the heritage of ActionScript as a dynamic language. ActionScript, Flex, and such appear to be based in the developers Java heritage. The result is a Java-ization of what used to be a dynamic browser environment into a fairly static Java webstart/applet-like environment.

So given that mxml generates AS code and I can duplicate that, then to some degree this code could be hand-written and be data-driven at runtime (i.e. be done via a "gui interpreter" of data just like a browser interprets HTML). I am going to look into this some more. The code is readable if not concise. It only needs to be done once.

I'd love to find out Flex provides an easy-to-program, dynamic GUI/graphics capability. Almost the opposite appears to be case so far. Several companies are apparently building apps like word processors for Apollo. They have to be doing some fairly low-level and efficient stuff with the text layout and redisplay. I wonder what level of the API they are using and how much code they've had to write themselves.

I could be missing wide swaths of the API that just isn't covered in the typical documentation aimed at building static GUIs in an IDE via XML.

3 comments:

Patrick Mueller said...

Time for you and Peter Fisk to have a conversation.

Patrick Logan said...

Good tip. Thanks.

john_r_nyquist said...

Your tip:
"Apparently all the controls in mx.controls can *only* be created through XML and the Flex mxmlc compiler."

Was VERY helpful, thanks!

I'm not clear on what you meant by the next sentence:
"Actually this is not strictly true since the -keep switch will keep around the generated ActionScript files."

Are you saying that once I compile an mx.control via the mxmlc compiler that I can then used the compiled output in an ActionScript program without going through an MXML file first?

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.