Ok... this is a bit of a long one.
I know the list has been quiet of late but Mike and I have been
consistently working on Vexi (just check SVN or the commit list) but
we tend to chat in Google Chat.
Firstly, since the Vexi community is only small (only my brother and I
and out various endeavours are known users of Vexi2) this is the time
to make major architectural decisions and we have made this one after
some discussion. I have posted a build to Sourceforge (core build
1845, widgets build 1844) which is stable and we will backport any
serious bug fixes to this build for anybody that might be using it.
Grid boxes are being removed from the core.
The impetus: they do not scale. The packing and layout may be
efficient in the core, but the overhead (through inability to
optimise) with the current combination of per-child layout preference
(packed vs unpacked) and 2D nature of grids.
A created, for a game prototype, a 50*50 grid of 20px*20x tiles. As a
grid () the performance was abominable. Mouse
events took seconds to register, rendering took unecessarily long to
occur. By removing the core grid ( with 50 child
) the performance issues disappeared.
If grids scale that badly (surely a 50*50 grid is not outrageous),
there is no point having them in the core. They can be better
simulated in JS, as demonstrated by the text widgets that use unpacked
layout to simulate flow and provide better performance than their
original grid packed flow.
The reasoning: grid boxes come with in-core baggage. They are a
trade-off - advanced layout but with significant overhead in both
storage and processing. The overhead comes when doing processing for
events like Enter and Leave - every mouse movement was registering a
loop that had to pass through all 2500 children of the grid box.
Because boxes could be unpacked (per child layout strategy) there is
no way to optimise this. Because layout is 2D, optimising options are
limited on a per-parent layout strategy if that change were made. In
addition, there is memory overhead with the grid implementation - each
box has row, col, rowspan, colspan, cols, and rows stored as Java
properties. We could move those to be JS properties but then that's
access overhead - may as well be part of a JS solution.
Just passing through this stuff now, the reduction in layout
complexity is staggering. Layout will be much, much quicker, and
rendering far quicker. Expect some demos over the next few days that
show off a far better performing Vexi (the build I posted above
doesn't perform badly, actually quite well outside of the large grid
scaling problems, but there will be a noticeable improvement after
So, if you are still reading, perhaps you are upset that grids will be
taken out the core. Well, the recent changes to Vexi mean that
implementing a grid box in JS is actually quite easy - much easier
than doing it in Java. The original reasons for putting it in the
core was the difficulty in doing it when Ibex was young but between
Mike and me we have implemented a number of features that make it a
much simpler task these days. Also the widgets barely use the core
grid features - the span properties are mentioned 3 times in the whole
of the widgets and values of greater than 1 for cols/rows are not used
much more. A value of 1 for cols/rows will translate directly into
the new layout strategy.
It's also a little misleading calling it a new layout strategy - we're
actually going back to something that is closer to what XWT once was.
What a journey, to go back to XWT roots. But we have gained a lot
along the way so it is not a backward step, just shedding some backage
that we no longer need to carry forward.
So, the new strategy, well I'll address that specifically in a follow up
Just to answer the FAQ about such decisions.
"Is this another one of those changes that will lead to months or
years of instability and cause yet more issues for anybody trying to
Short answer: no!
Long answer: this is simplification of code, simplification of logic,
and improvement in performance. All the other decisions that have
caused the long arduous road from XWT thus far added significant
complexity. This is the opposite kind of design decision.
Yes, we could have gone half-way and kept grid boxes in the core but
changed layout from per-child to per-parent and gained some benefit in
terms of reduced processing, but given the gains of removing it
altogether [memory, additional processing optimizations], I have
become resolutely convinced it is best to make both changes at once.
PS. Removing grid boxes (although I'm not sure about per-parent
layout) was also something Adam announced he wanted to do with Ibex
some time ago. It's funny how often I belatedly agree with him. :-)
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.