Generation of HTML is extremely fast, but compressing thousands
of frames for wireframe animated GIFs can take a little while.
Sharing bitmaps between threads required two changes: (1) bitmaps
need to be "frozen" after being drawn; (2) you can't use Path because
BackgroundWorker isn't a STAThread. You can, however, use a
DrawingVisual / DrawingContext to do the rendering. Which is really
what I should have been doing all along; I just didn't know the
approach existed until I was forced to go looking for it.
Also, we now do a "run finalizers" call before generating an animated
GIF. Without it things explode after more than 10K GDI objects have
been allocated.
Experimented with different orders of rotation for wireframe viewer.
Made perspective projection the default behavior. Removed animation
parameters from the stored Visualization when it's not animated.
Moved X/Y/Z rotation out of the plugin, since it has nothing to do
with the plugin at all. (Backface removal and perspective projection
are somewhat based on the data contents, as is the choice for
whether or not they should be options.)
Added sliders for X/Y/Z rotation. Much more fun that way.
Renamed VisualizationAnimation to VisBitmapAnimation, as we're not
going to use it for wireframe animation. Created a new class to
hold wireframe animation data, which is really just a reference to
the IVisualizationWireframe so we can generate an animated GIF
without having to pry open the plugin again.
Renamed the "frame-delay-msec" parameter, which should start with
an underscore to ensure it doesn't clash with plugin parameters.
If we don't find it with an underscore we check again without for
backward compatibility.
I did a bunch of experiments to characterize line drawing. Long
story short: end points are inclusive, and coordinates should be
offset by +0.5 to avoid anti-aliasing effects.
The visualization editor was retaining an IPlugin reference for the
visualization generator selection combo box. After 5 minutes the
proxy object timed out, so if you left the editor open and inactive
for that long you'd start getting weird errors.
We now keep the script identifier string and use that to get a
fresh IPlugin proxy object.
We now store Visualizations, VisualizationAnimations, and
VisualizationSets as three separate lists linked by tag strings.
WARNING: this breaks existing projects with visualizations. The
test projects have been updated.
Bitmap animations are composed of a sequence of other visualizations.
This is all well and good until a visualization is deleted, at which
point all animations in all sets in the entire project have to be
checked and potentially changed, and perhaps even removed (if all of
the animation's members have been removed). This turns out to be
kind of annoying to deal with, but it's better to deal with it in
code than force the user to manually update broken animations.
This change adds thumbnails for the animations, currently generated
by offscreen composition. This approach doesn't work quite right.
This adds a new class and a rough GUI for the editor. Animated
visualizations take a collection of bitmaps and display them in
sequence. (This will eventually become an animated GIF.)
Fixed the issue where changes to tags in the set currently being
edited weren't visible to the tag uniqueness check when editing other
items in the same set.
Report visualization generation errors through an explicit
IApplication interface, instead of pulling messages out of the
DebugLog stream.
Declare that GetVisGenDescrs() is only called when the plugin is in
the "prepared" state, so that plugins can taylor the set based on
the contents of the file. (This could be used to set min/max on
the "offset" entries, but I want special handling for offsets, so
we might as well set it later.)
Various improvements:
- Switched to ReadOnlyDictionary in Visualization to make it clear
that the parameter dictionary should not be modified.
- Added a warning to the Visualization Set editor that appears when
there are no plugins that implement a visualizer.
- Make sure an item is selected in the set editor after edit/remove.
- Replaced the checkerboard background with one that's a little bit
more grey, so it's more distinct from white pixel data.
- Added a new Apple II hi-res color converter whose output more
closely matches KEGS and AppleWin RGB.
- Added VisHiRes.cs to some Apple II system definitions.
- Added some test bitmaps for Apple II hi-res to the test directory.
(These are not part of an automated test.)
Thumbnails are now visible in the main list and in the visualization
set editor. They're generated on first need, and regenerated when
the set of plugins changes.
Added a checkerboard background for the visualization editor bitmap
preview. (It looks all official now.)
The Visualization and Visualization Set editors are now fully
functional. You can create, edit, and rearrange sets, and they're
now stored in the project file.
Got parameter in/out working in EditVisualization dialog. Did some
rearranging in PluginCommon interfaces and data structures. Still
doesn't do anything useful.
Basic infrastructure for taking a list of parameters from a plugin
and turning it into a collection of UI controls, merging in values
from a Visualization object. Doesn't yet do anything useful.
WPF makes the hard things easy and the easy things hard. This was
a hard thing, so it was easy to do (with some helpful sample code).
Yay WPF?
