Massive code changes to produce arguably better (but possibly not) support for type specific parameters within ParameterLists. Changes to this have vastly far reaching affect on almost the entire code base due to how many things use ParameterLists and how the 2 core functions for using them were literally removed from the object. My appologies to anyone in the middle of writing FractalPlugins or RenderPanels and of course all old users of ParameterLists must be brought up to date with the current interface. (Which is of course why this change is so far reaching.)

Supported types include Double (all it supported before), Long, Boolean, String, and File. (String and File are not yet implemented.) This will allow finer control over what data can be entered by the user when setting parameters and also better detection of how to use those values when accessing the parameters in code.

Today I'm finally working on the GUI allowing the user to adjust ParameterLists. I've been ignoring this extremely important feature for a long time due to the fact that it's not all that exciting to develop. Since so many cool new features I have planned will rely on this boring feature, it has now become my first development priority.

Included in this feature is the retro-fitting of ParameterList support into all existing RenderPanels. This will allow felxibility into RenderPanels that can let developers make them very interesting and it also unifies the underlying configuration system neatly on to ParameterLists. To verify this new support I added support for disablable color channels to BasicRenderPanel. Also a new ParameterListGui class that is the actual display to the user, ParameterListTableModel for supporting the table in that dialog, and several new methods in ParameterList to support the TableModel were all added. Finally, RenderPanel has been revised to include enableForcedRender() that enables a single forced render when the RenderPanel is painted. This allows RenderPanel settings to be shown instantly upon being set.

First time in a while I've done any work on this project. During the last month and change, I have touched the code every now and then in an effort to add to the framework the abilty to create multi-threaded FractalPlugins. I determined that the easiest way to create multi-threaded fractals was to divide the work of generating a fractal into multiple chunks. This produced the concept for the new class called FractalMtWorker. Any class containing Mt indicates that it is designed as part of the multi-threaded framework.

Once that framework was mostly in place I began developing a multi-threaded Mandelbrot plugin and a multi-threaded Mandelbrot worker class to do the work. The idea is that the plugin acts to the system like any other FractalPlugin but in reality all it does it divide up the work to be done, start all the workers, wait for them to finish, and collect the data they produce. Due to the overhead of percent messages that would be collected from any number of MandelbrotMtWorkers, the MandelbrotMtPlugin only sends percent update messages when a worker sends a message indicating that is is done.

While I haven't yet tested the Mt framework on a true multi-CPU computer, I have tested it on a computer with HyperThreading and seen a small improvement in performance over the single threaded MandelbrotPlugin. Graphically, the images produced seem identical between the single and multi-threaded versions.

To support this framework, new merge methods were added to FractalBuffer. Also the new super-class of all multi-threaded fractal workers was created and is called FractalMtWorker.

Today I added several helper methods to ComplexNumber. These include more accurate distance from origin calculations, a check to determine whether the ComplexNumber is equal to 0 + 0i, and the ability to get a String version of the ComplexNumber for display purposes. In addition to these a NewtonPlugin was written to push the bounds of fractal math and logic a bit further for me. I'm not entirely convinced that it represents an actual Newton fractal based on images I've seen, but it does at least produce images.

A friend's attempt to write a FractalPlugin sent me on a wild goose chase to figure out why MonkeyFractal refused to load the class he was passing in. At the end of a lot of searching Google and asking friends, it was determined that the manifest file in the jar file needed to have its class path revised. Specifically from none specified to having one that points at the current directory. Apparently the class path provided on the command line was being ignored entirely due to trying to run the program as a jar file.

Today I coded a PlasmaPlugin which does a genuinely horrible job at producing Plasma fractals that are anything except perfectly square. I also coded a PlasmaRenderPanel which produces wonderful colors for the PlasmaPlugin generated fractals, but does a pretty poor job with either Mandelbrot or Julia. (Not entirely sure why yet.)

Future Plans: (Some items copied from previous development notes.)

• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things. Edit: Without it, the program must be restarted with new parameters to swap the plugins. The goal is to avoid that entirely and simply allow fully dynamic swapping.
• Add a "Back Button" style system to allow for zooming back out. This will likely be implemented by simply saving ComplexRange values in an ArrayList and then reusing and removing the values as the Back Button is used.
• Create an applet friendly version of the FractalWindow that allows a basic model of the program to operate in a web page.
• A user save file dialog will be added to allow the user to choose the location, name, and type of file that will be saved.
• A "blind generation" mode that uses a configuration window to set it up and can generate massively high resolution fractals without ever showing them on the screen. These massive fractals would then be directly saved to an image file. This should allow the program to generate fractals, possibly overnight, to be used in prints or posters.

My goal for today was to work through some of the changes outlined in previous notes and see how everything flies. Sorry to anyone that is trying to develop FractalPlugins or RenderPanels since the parent classes and function prototypes keep moving around. I'm really just trying to make it easier and cleaner in the end.

Today's Progress:

• Architecture Change: ComplexNumber non-static math functions are now named the same as the static versions. I realized I didn't need to use different names since they all take in one less ComplexNumber. Also added a couple of setters and getters for developers out there that dislike direct field access. These changes required adjustments to MandelbrotPlugin and JuliaPlugin.
• Added a copy method to the FractalBuffer class that will produce a deep copy of the FractalBuffer. This can potentially help reduce the skewed lines of partial renders.
• Added a menu to the main window. Several future activities will be controllable from the menu.
• Added a Help About dialog box. It shows core program information as well as information provided by the plugins. Modified FractalPlugin and RenderPanel to have abstract methods that provide their own Help About info. Modified BasicRenderPanel, MandelbrotPlugin, and JuliaPlugin to implement this method.
• Architecture Change: RenderPanel was modified to no longer have protected access to its fields by its children. Methods were reworked to accept parameters and return things appropriately so the method's purpose is now more obvious by the function prototype alone. BasicRenderPanel was revised to reflect this change.
• Architecture Change: FractalPlugin was modified to no longer have protected access to its FractalBuffer field. (Which was actually removed entirely.) generateFractal() was reworked to accept parameters and return things appropriately so the method's purpose is now more obvious by the function prototype alone. MandelbrotPlugin, JuliaPlugin, FractalThreadManager, and FractalWindow were all revised to reflect this change.
• The ability to save the previously rendered (typically the currently visible) fractal image as a JPG, BMP, PNG, or GIF file has been added. At the moment, the location and name of the file are not user selectable. In fact which type isn't either. It simply saves all four files. A Save dialog will be added in the near future.
• Added a system I call the "hard lock" system to the FractalWindow. This system prevents basically all activities from stepping on each other. This system is tied into starting a render and is not released until it has sent a complete message. While hardLock is on, window resizing, rubberband box, and several other features are entirely ignored. This can result in rendered images that are mismatched with the displayed size of the window, but over all it seems to resolve thread race conditions that were lurking around as well as the ability to cause multiple fractals to generate concurrently.

Future Plans: (Some items copied from previous development notes.)

• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things. Edit: Without it, the program must be restarted with new parameters to swap the plugins. The goal is to avoid that entirely and simply allow fully dynamic swapping.
• Add a "Back Button" style system to allow for zooming back out. This will likely be implemented by simply saving ComplexRange values in an ArrayList and then reusing and removing the values as the Back Button is used.
• Create an applet friendly version of the FractalWindow that allows a basic model of the program to operate in a web page.
• A user save file dialog will be added to allow the user to choose the location, name, and type of file that will be saved.
• A "blind generation" mode that uses a configuration window to set it up and can generate massively high resolution fractals without ever showing them on the screen. These massive fractals would then be directly saved to an image file. This should allow the program to generate fractals, possibly overnight, to be used in prints or posters.

There was no actual new development today, but several things I would like to remember to code in the near future. I've added to the future development list.

Future Plans: (Some items copied from previous development notes.)

• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things. Edit: Without it, the program must be restarted with new parameters to swap the plugins. The goal is to avoid that entirely and simply allow fully dynamic swapping.
• Add a "Back Button" style system to allow for zooming back out. This will likely be implemented by simply saving ComplexRange values in an ArrayList and then reusing and removing the values as the Back Button is used.
• Create an applet friendly version of the FractalWindow that allows a basic model of the program to operate in a web page.
• After a conversation with a friend about project architecture I decided that it makes sense to change a few things. Specifically the rather vague requirement of placing data into parent class variables is downright bad. Any methods that require such an activity need to be revised and must have the JavaDocs changed to reflect this.
• The ability to save fractal images as some sort of stand-alone image format would be an excellent feature. The present requirement is take a screen shot of the program and edit out the edges of the window manually. Likely supported output formats include BMP, TGA, and JPG.
• A "blind generation" mode that uses a configuration window to set it up and can generate massively high resolution fractals without ever showing them on the screen. These massive fractals would then be directly saved to an image file. This should allow the program to generate fractals, possibly overnight, to be used in prints or posters.

Today was a day of optimization and research into effective ways to make swapping plugins dynamically possible.

• FractalWindow no longer has a default FractalPlugin or RenderPanel. They must be supplied by the appropriate methods. The MonkeyFractal driver was modified accordingly to accept command line parameters representing the class names to load for these things. Attempting to run MonkeyFractal without supplying the class names to use will result in the display of the proper syntax for running the program. Several confusing thread race conditions arose, but appear to be corrected at this point.
• FractalWindow and UpdateMessage were modified to add support for showing elapsed time of activities such as fractal generation. See JavaDocs on UpdateMessage to see the new type. The time display label is on the left at the bottom of the main window.
• ComplexNumber was revisited due to a theory about the speed impact of all the math functions being static and creating new ComplexNumbers all the time. A new set of functions that avoid object creation entirely were created. These new functions were incorporated into both MandelbrotPlugin and JuliaPlugin and both aproximately doubled in generation speed as a result of this optimization. It is highly recommended that all FractalPlugins that need ComplexNumber math use the new non-static versions of these functions.

Future Plans: (Some items copied from previous development notes.)

• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things. Edit: Without it, the program must be restarted with new parameters to swap the plugins. The goal is to avoid that entirely and simply allow fully dynamic swapping.
• Add a "Back Button" style system to allow for zooming back out. This will likely be implemented by simply saving ComplexRange values in an ArrayList and then reusing and removing the values as the Back Button is used.
• Create an applet friendly version of the FractalWindow that allows a basic model of the program to operate in a web page.

Several of the previous day's development "Future Plans" were implemented today. Minor design changes were made to improve the overall project archetecture.

• FractalPlugin was made into an abstract super class and both MandelbrotPlugin and JuliaPlugin were revised to support the changes. The implementations of several simple functions were moved into the parent FractalPlugin. Overall these changes mean easier FractalPlugin development.
• FractalPlugin was almost untouched to add in support for multi-threaded generation of fractals. Through the addition of only one method on FractalPlugin, the revision of a couple others and the creation of a new class called FractalThreadManager, FractalPlugins are now properly running in their own threads. If a FractalPlugin would like to send update messages to the GUI (an activity which is highly recommended for things such as informing the user of the percent complete on the fractal from time to time during generation) they need only use threadManager.sendUpdate().
• RenderPanel and BasicRenderPanel were reworked to better handle rendering tasks (they are a good deal faster now) and to fully support a visible rubber band box for zoom selection. FractalWindow was then modified to properly relay rubber band box information to the RenderPanel.
• The start button was removed from the window and a percent label area was added. Regeneration of fractals is now automatic following events such as initial load, window resize and zooming in.

Future Plans: (Remaining items copied from previous development notes.)

• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things.

The first official day of coding saw a lot of progress. The basics are in place at this point. The skeleton and proof of concept of generic ParameterList support, simple blind zooming control, a basic RenderPanel, and two FractalPlugins (Mandelbrot and Julia) are all working.

Before continueing the development, a brief pause was made to fully JavaDoc the code. Additional planned features were considered and how they will eventually work were thought about long and hard. The desire to keep things generic so this can remain a fully plugin based application is very strong and has at least a couple times forced me to go back and rethink things.

Future Plans:

• FractalPlugin is likely to be made into an abstract super class. Presently its an interface and some of the future interface qualifies as the sort of thing that should not be reimplemented every time by FractalPlugin developers.
• FractalPlugin will be changed to support multi-threaded behavior. This will allow the FractalWindow to continue to operate normally during fractal generation as well as provide real-time feedback to the user instead of leaving them wondering if the program is even still working.
• Visible rubber-band box support for zooming controls. This feature set must also include intelligent swapping of values to prevent backwards zoom ranges. To make this work, several revisions to how RenderPanels work will need to be made, including storage of drawn fractal as an Image to prevent redrawing/regenerating of the fractal during rubber-band box rendering.
• A window that allows the manual revision of ParameterList settings for either FractalPlugins or RenderPanels needs to be created. In general, most fractals require parameters outside of the standard zoom range values that presently have no way to be set outside of a recompile.
• A window that allows swapping (possibly even intelligently in some way such as a dynamically loaded list) of FractalPlugins and RenderPanels is required. Without it, the program must be recompiled to swap these things.
• The removal of the start button is also a must-do. This will occur after the multi-threaded behavior of FractalPlugins is complete. When fractal data must be recalculated is easy enough to determine without user interaction.