Form and Function

It appears there is a known bug in the Flash Player that creates rendering artifacts and uneven results when trying to apply strokes to a corner radius.  Let me outline the situation by having you look at the attached image with three separate rectangles and the associated code for each.

So for the left rectangle we used the code below, and one would expect a nice pretty red rectangle with a smooth black stroke and 6 pixel corner radius, but what we get is a rectangle with 4 uneven corner and these weird rendering artifacts which extend beyond the boundary of the shape.

graphics.drawRoundRectComplex(10,10,100,30,6,6,6,6);

For the middle rectangle we set the "pixelHinting" property of the lineStyle to true, and this seems to remove the funky artifacts, but still leaves the different radius on the corners.

For the right most rectangle it appears we have it drawn correctly, but we were only able to do this by NOT using any line style at all, and instead having to create two rectangles with one nested inside the other.

So it is obvious to me that the Player is capable of rending this correctly, but it does NOT.  I am not sure if the cause is in some type of sub-pixel interpolation algorithm, or it lies within the "curveTo" code for line strokes where the player might be using some type of cubicBezier algorithm and the control points are too close together to get an accurate curve.

It appears that the Flex team is aware of this issue and thus renders all of its "cornerRadius" borders by applying the same technique I am using above by doing two separate compexRectangle fills.

So apparently Adobe is well aware of this issue, and from what I understand, through unnamed sources, this isn't even on the radar for the next major release (Flash Player 10.)  I think is a real shame since I believe it really undermines the quality of what can be produced with Flash when you want a high level of detail and your are forced to take a bunch of unnecessary hacks to work around it.

I was a bit concerned attending the event that I would not see eye-to-eye with some of these other experts, since I hold a relatively contrarian view when it comes to designing dashboard solutions.  I believe that ALL business intelligence systems need to be designed from the top (user) down, versus the bottom (data) up.   Pretty much all big BI vendors and industry experts have been preaching the bottom-up mantra for the past 20 years. 

On the flight back from the summit I wrote an article that (hopefully) more clearly articulates my position and the logic behind it.  You can read it here.   In a nutshell I basically state that Big BI and current industry experts have a strong financial interest in not rocking the status quo, and are in fact hindering the efficacy of the very solutions they purport to be advancing.

By any objective measure, BI is long way away from reaching its potential, especially in the eyes of business users and organizations who have implemented seven figure BI solutions.  My thesis is that because BI has its history rooted in the collection, transformation, aggregation and dissemination of data that the lions share of focus on any BI project revolves around the data and the not the end user.   Reports and dashboards end up being after-thoughts at the end of big BI initiatives.     

The BI industry has created its wealth through the selling of these solutions and expertise and insist they are needed to provide an effective BI solution.   In my experience this is absolutely NOT the case.  You can create a very effective dashboard solution with a very minimal BI infrastructure, although in some cases having a robust BI back end is definitely going to make things easier.   As I mention in my article the BI leaders have painted themselves into a corner because even if they recognize the back end is not the place to start, they would end up undermining their primary revenue streams (not to mention customer confidence) if they openly acknowledged this state of affairs.

What I suppose will begin happening, is that more and more start up companies will start to address this schism and we will see a slow movement to more user-centric BI solutions that focus on business and user requirements with online tools that allow integration of distributed and heterogenous data.  At the same time I still see a very valid place for traditional BI, as there are still thousands of companies with vast stores of transactional data that needs to be collected, processed, and aggregated into common structures that can be used to help feed the user-centric BI solutions.

One of the first areas of Degrafa I started working on was a revamp of the current Repeater objects.  Jason had some cool ideas on what we could do to make repeaters more concise, flexible, and powerful.   After a couple of IM chats I had a reasonably good idea of what we wanted to accomplish and I rolled up my sleeves to see what I could do.   You can see the most current rev in our Dev branch at Google Code, although I suspect we will end up cleaning up some of the name spacing and move the new GeometryRepeater class somewhere else.

One of the challenges the current Degrafa Beta 2 suffers from is that we have a myriad of specific geometry repeater classes like Line, Circle, Rectangle, etc...    Not only does this clutter up our core class libraries, but it is also much less flexible than it can be.

The new architecture we are developing takes a different approach, instead of creating gemoetry specific repeater classes we wanted to create an abstract repeater engine.   This is accomplished through our GeometryRepeater class which inherits from Geometry and implements the IRepeaterModifier interface via its modifiers array.  Okay, so what does this all mean?

1.  You define the geometry you want repeated with any number of Degrafa geometry objects, which can be separate objects or complex compositions.   You are no longer limited to the current repeater classes, but can easily repeat ANY Degrafa geometry you create.

2. You define HOW the geometry repeats via one or more IRepeaterModifiers.   Initially we have created a PropertyModifier that allows you to target one or more geometry objects within your GeometryRepeater and an associated property you want to modify.  You can have as many RepeaterModifiers as you want to create composited repetitions.  Over time we may add additional core modifiers, or you can create your own by implementing the IRepeaterModifier interface.

Below you can see how one might implement a Circle repeater that repeats along a horizontal Axis:

For a more complex example you can check out this demo that has view source enabled.

When you look at the demo you will see a simple circle geometry that is being repeated 30 times with multiple property modifiers being applied to it.  If you look at the code there are some interesting things to note here about the PropertyModifier class.

1.  We support targeting common properties across multiple targets via just one repeater like are doing here with the myCircle and myRect in the targets properties.  We also support not only direct object properties, but also descendent properties via a dot notation (look at the property="fill.alpha") setting for example:

2. We support built in static operators as well as offset functions.

Not only can you provide static offset amounts (as in the example above) with fixed operators like add, subtract, or none you can also provide offsets as an array that will behave like a modulo function against the iteration number as in the radius modifier below.   Additionally you can also provide offsets as dynamic functions as in the fill.color modifier that uses the custom colorOffset function found in the sample source files.

There are many more advanced features, but I will wait until we have pinned down the exact functionality for our Beta 3 release before delving into it further.  Please check out the sample, and use view source to get an idea of what is possible.

Over the past couple of months I have become more deeply involved in the open source Degrafa project that was started by Juan Sanchez and Jason Hawryluk over 1 year ago.   Today the Degrafa team has grown quite substantially and I represent the 8th official team member.

There were three primary motivations for me joining the Degrafa team.

Reason 1.  Degrafa just plain ROCKS!  

What I love most about Degrafa is that it represents an extremely expressive, yet compact markup syntax to produce amazing graphical assets.  Basically it allows me to do some really cool things with very little code.

Degrafa leverages the low level flash drawing API's to implement sophisticated vector and raster rendering via MXML markup.   What does this mean to your average Flex developer?  It means that you no longer have to resort to working in Flash or other vector based tools to create complex vector assets, and you no longer have to struggle with using procedural API's to manually draw your graphics.   Degrafa piggy-backs off of the same metaphors that most XML based markup syntax does, in that the nested XML structures you use to define your page layout create a visual corollary to the actual physical layout of the code.   With XML markup you can easily see the primary relationships between objects due to their nesting structures.  

When you combine XML Markup with Flash/Flex's powerful binding mechanism you get a very expressive, compact, and intuitive way to code graphical assets.     One example of this effect in action can be seen in some of the GeometryRepeater code I have been working on for Degrafa (to be covered in a later blog post.)  I was able to take a couple very simple base classes and in less than 15 lines of MXML and 10 lines of AS create a completely dynamic single series Column/Area/Point/Line chart.   That is 25 lines of total code, that is what I call powerful!

When I started working with Flex in late 2005, I had never been directly exposed to the open source community and always regarded the open source movement with a detached fascination and certain level of disbelief that so many developers would volunteer their time for an apparently non-commercial effort.  Over the past couple of years, my eyes have been opened to the many advantages to open source on commercial, personal, and social level.   In learning Flex and watching the growth of the community I have repeatedly reaped the benefits of others efforts in many areas ranging from free (and excellent) components, blogs, and sharing of ideas.  

I think an individual can only "take" for so long before starting to feel an indebtedness and desire to give back to the community.  Probably most of all is the great level of personal satisfaction I receive when I contribute something to the community that others find great value in.   I probably receive more satisfaction from releasing a component I spent time working on and seeing many people positively respond to it in my blog than I do from landing a large consulting contract.

Both Jason and Juan (the two founders of degrafa) are so genuinely enthusiastic about the project and immanently accessible.  When I dove into Degrafa for the first time a couple of months back for work on my Gauge component I started trading e-mails with Juan, which quickly led to multiple chat sessions per day.  Juan was always available to answer questions and point me in the right direction, and then he connected me with Jason, who was equally accessible and helpful.   Once I started working with Jason and he showed me the guts of Degrafa I realized "wow, these are some truly bright people, creating a really amazing framework."  I was hooked.

Moving forward my role at Degrafa will probably have many facets, but I will most likely be focusing as a direct contributor to the core engine as well as helping to provide  some organizational support for Degrafa as an entity and open source project.

The difference in the new iPhone design is that the edges appear to be more sculpted like a Mac Book Air, thus the phone probably "feels" thinner, when in reality it is thicker.