Fusion Trunk Status Update

[Paul Spencer-2]

I thought I would give everyone a quick update on the status of my Jx  
update and a couple of other things.

There are four topics to address:

  * the build process update
  * the Jx update
  * the new imagestrip generator
  * overall improvements from the above

The Build Process
=================

The build process has been cleaned up a bit and the logic for building  
a single file build has been improved, now if you run ant compress it  
will produce a single file build for everything, unless you specify an  
appdef in which case it will include just what is required for that  
app (plus the json version of the appdef) - and compress the whole  
thing using YUI compressor.  It is now simpler to build a compiled  
version of everything, which is ultimately what we want the default  
distribution to use.

Jx
==

The Jx update is basically done except for some testing and a few  
minor quirks that I need to address.  I have merged my changes from  
fusion/sandbox/jx2 into trunk today.

Before you rush off to update, there are a couple of things to note:

1) the Jx API has changed, which means if you are using Jx in your  
template (index.html) to create tabs, panels, dialogs etc then some  
things will need to be updated.  I have updated the standard templates  
that ship with fusion in SVN (at least the mapserver one, I still have  
to check the mapguide one).  I will send a separate email describing  
the major API changes.

2) If you have created a custom skin for Jx (like the MapGuide  
templates), the CSS and images for those will need to be completely  
redone to match the new way we are doing things.  I seriously doubt  
anyone has done this except for DMSG otherwise would have heard about  
it ;) so the impact should be small (except for the mapguide templates).

A quick background on the Jx changes.  The Jx update has been  
undertaken to achieve several goals (not all directly related to  
Fusion per se):

1) reduce the size of the library by switching from Prototype/
Scriptaculous to MooTools
2) to standardize the Jx API and CSS files
3) to simplify the internal construction of various objects - now many  
things share a common base class that provides the basic structure
4) to simplify the process of creating a new visual skin for Jx
5) reduce CPU usage by relying as much as possible on CSS and the  
browser's layout engine rather than javascript
6) add some new features (such as menus that automatically adjust  
their position so they don't go off the page)
7) add more visual effects (drop shadows, animations etc)

We have largely achieved these goals, although we didn't get to adding  
any animation effects yet.

The end result is a slimmer library (almost 50% reduction), a much  
cleaner code base and CSS, reduced CPU load, better memory management,  
etc.

Bringing this code into Fusion, though, presented a couple of  
challenges.  The mechanics of updating to use the new Jx API was  
relatively straight forward, but it highlighted a few things that I  
felt were pretty broken in the core architecture of how widgets are  
created and represented.  I took the opportunity to revise this core  
architecture with the end result of simplifying widget creation and  
activation logic, simplifying the creation of new widgets (less to do  
for simple widgets), and completely removing four base classes  
(several hundred lines of code) that were just not necessary anymore.  
There is probably more that could be done with the core widget  
architecture but I am pretty satisfied with the work to date and don't  
plan to do any more at this time.

Image Strip Generator
=====================

I have also added a new image strip generator (php command line  
script) that can be used to generate a single image and a CSS file  
from a set of icon images.  These can be used by an application to cut  
out a large number of requests for individual icons in buttons and  
menu items.  Here is how I used it on the MapServer standard template  
that comes with Fusion:

1) in a command prompt, change directories to the images/icons  
directory in the application and run:

$ /path/to/php /path/to/fusion/utils/imagestrip.php -css ../../
icons.css -o ../icons.png *.png

This generates a CSS file in the root directory of the application (it  
can go wherever you want) and a single image in the images directory

2) edit the template index.html file and include the new CSS (after  
the jx skin CSS file)

<link rel="stylesheet" href="icons.css" type="text/css" media="screen"  
charset="utf-8">

3) edit the application definition and update all the widgets by  
changing the ImageUrl to point to the new icons.png file (yes all of  
them point to the same image) and setting the ImageClass to be the CSS  
class for that icon (which was taken from the file name)

So if you had:

       <ImageUrl>images/icons/zoom-in.png</ImageUrl>
       <ImageClass/>

you would end up with:

       <ImageUrl>images/icons.png</ImageUrl>
       <ImageClass>zoom-in</ImageClass>

my text editor has a regular expression search/replace feature that  
let me do it in one step:

search for:
       <ImageUrl>images/icons/(.*).png</ImageUrl>
       <ImageClass/>

replace with:
       <ImageUrl>images/icons.png</ImageUrl>
       <ImageClass>$1</ImageClass>

Combined Improvements
=====================

Old method, worst case: the default install, not compressed, load  
individual widget files:

128 requests, 648 kb, 6.45 seconds

New method (compressed, single file, image sprites for icons):

52 requests, 254 kb, 4.3 seconds

both methods are using gzip compression from the web server so the  
actual file sizes are larger in both cases, but I think this is a fair  
comparison.

Also, there was a compressed build option for 1.0/1.1 which would have  
reduced the number of requests and size somewhat, bringing it a bit  
closer to the new method in terms of requests and size, although it  
doesn't have the image sprite capability for icons which means more  
requests and the new Jx is quite a bit slimmer (almost half the size  
because of the underlying library change from prototype to mootools).

Overall, I am moderately happy that we have achieved the improvements  
we were looking for in this update (less HTTP requests, smaller  
overall file size, improved runtime performance) and have a few new  
features to play with.

There will be a few more things coming for the next version including  
an optimization to the LoadMap process to allow faster initialization  
- the goal is to get a map on the page as quickly as possible, after  
all - and possibly the ability to generate sprites for legend images  
(we have a tentative version for mapserver, not sure if we will have a  
mapguide equivalent or not).

Cheers

Paul

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Paul Deschamps]

Fantastic. I can't wait to use it in the next application. ;)

A 50% reduction of code is amazing. nice job

Cheers

Paul D.

On Thu, Sep 11, 2008 at 4:07 PM, Paul Spencer <[hidden email]> wrote:

I thought I would give everyone a quick update on the status of my Jx update and a couple of other things.

There are four topics to address:

 * the build process update
 * the Jx update
 * the new imagestrip generator
 * overall improvements from the above

The Build Process
=================

The build process has been cleaned up a bit and the logic for building a single file build has been improved, now if you run ant compress it will produce a single file build for everything, unless you specify an appdef in which case it will include just what is required for that app (plus the json version of the appdef) - and compress the whole thing using YUI compressor.  It is now simpler to build a compiled version of everything, which is ultimately what we want the default distribution to use.

Jx
==

The Jx update is basically done except for some testing and a few minor quirks that I need to address.  I have merged my changes from fusion/sandbox/jx2 into trunk today.

Before you rush off to update, there are a couple of things to note:

1) the Jx API has changed, which means if you are using Jx in your template (index.html) to create tabs, panels, dialogs etc then some things will need to be updated.  I have updated the standard templates that ship with fusion in SVN (at least the mapserver one, I still have to check the mapguide one).  I will send a separate email describing the major API changes.

2) If you have created a custom skin for Jx (like the MapGuide templates), the CSS and images for those will need to be completely redone to match the new way we are doing things.  I seriously doubt anyone has done this except for DMSG otherwise would have heard about it ;) so the impact should be small (except for the mapguide templates).

A quick background on the Jx changes.  The Jx update has been undertaken to achieve several goals (not all directly related to Fusion per se):

1) reduce the size of the library by switching from Prototype/Scriptaculous to MooTools
2) to standardize the Jx API and CSS files
3) to simplify the internal construction of various objects - now many things share a common base class that provides the basic structure
4) to simplify the process of creating a new visual skin for Jx
5) reduce CPU usage by relying as much as possible on CSS and the browser's layout engine rather than javascript
6) add some new features (such as menus that automatically adjust their position so they don't go off the page)
7) add more visual effects (drop shadows, animations etc)

We have largely achieved these goals, although we didn't get to adding any animation effects yet.

The end result is a slimmer library (almost 50% reduction), a much cleaner code base and CSS, reduced CPU load, better memory management, etc.

Bringing this code into Fusion, though, presented a couple of challenges.  The mechanics of updating to use the new Jx API was relatively straight forward, but it highlighted a few things that I felt were pretty broken in the core architecture of how widgets are created and represented.  I took the opportunity to revise this core architecture with the end result of simplifying widget creation and activation logic, simplifying the creation of new widgets (less to do for simple widgets), and completely removing four base classes (several hundred lines of code) that were just not necessary anymore.  There is probably more that could be done with the core widget architecture but I am pretty satisfied with the work to date and don't plan to do any more at this time.

Image Strip Generator
=====================

I have also added a new image strip generator (php command line script) that can be used to generate a single image and a CSS file from a set of icon images.  These can be used by an application to cut out a large number of requests for individual icons in buttons and menu items.  Here is how I used it on the MapServer standard template that comes with Fusion:

1) in a command prompt, change directories to the images/icons directory in the application and run:

$ /path/to/php /path/to/fusion/utils/imagestrip.php -css ../../icons.css -o ../icons.png *.png

This generates a CSS file in the root directory of the application (it can go wherever you want) and a single image in the images directory

2) edit the template index.html file and include the new CSS (after the jx skin CSS file)

<link rel="stylesheet" href="icons.css" type="text/css" media="screen" charset="utf-8">

3) edit the application definition and update all the widgets by changing the ImageUrl to point to the new icons.png file (yes all of them point to the same image) and setting the ImageClass to be the CSS class for that icon (which was taken from the file name)

So if you had:

     <ImageUrl>images/icons/zoom-in.png</ImageUrl>
     <ImageClass/>

you would end up with:

     <ImageUrl>images/icons.png</ImageUrl>
     <ImageClass>zoom-in</ImageClass>

my text editor has a regular expression search/replace feature that let me do it in one step:

search for:
     <ImageUrl>images/icons/(.*).png</ImageUrl>
     <ImageClass/>

replace with:
     <ImageUrl>images/icons.png</ImageUrl>
     <ImageClass>$1</ImageClass>

Combined Improvements
=====================

Old method, worst case: the default install, not compressed, load individual widget files:

128 requests, 648 kb, 6.45 seconds

New method (compressed, single file, image sprites for icons):

52 requests, 254 kb, 4.3 seconds

both methods are using gzip compression from the web server so the actual file sizes are larger in both cases, but I think this is a fair comparison.

Also, there was a compressed build option for 1.0/1.1 which would have reduced the number of requests and size somewhat, bringing it a bit closer to the new method in terms of requests and size, although it doesn't have the image sprite capability for icons which means more requests and the new Jx is quite a bit slimmer (almost half the size because of the underlying library change from prototype to mootools).

Overall, I am moderately happy that we have achieved the improvements we were looking for in this update (less HTTP requests, smaller overall file size, improved runtime performance) and have a few new features to play with.

There will be a few more things coming for the next version including an optimization to the LoadMap process to allow faster initialization - the goal is to get a map on the page as quickly as possible, after all - and possibly the ability to generate sprites for legend images (we have a tentative version for mapserver, not sure if we will have a mapguide equivalent or not).

Cheers

Paul

__________________________________________

  Paul Spencer
  Chief Technology Officer
  DM Solutions Group Inc
  http://www.dmsolutions.ca/

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Paul Spencer-2]

I'm not sure we can claim fully 50% - the uncompressed numbers include  
code comments while the compressed numbers don't, we'll need to use a  
compressed version of the existing library to get a more accurate  
assessment (and not use gzip from the server to see the actual  
numbers).  But it is a substantial improvement nonetheless.

On 11-Sep-08, at 4:29 PM, Paul Deschamps wrote:

> A 50% reduction of code is amazing. nice job


Cheers

Paul

__________________________________________

    Paul Spencer
    Chief Technology Officer
    DM Solutions Group Inc
    http://www.dmsolutions.ca/

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev