It’s been a long slog, much longer than I expected, but now I have something working in terms of a real (and persistent) history of saved shapes (and their parameters and tieflume code to create) in my “blob” (compositeFile). I managed to install all the various history options and get a really simple “inspector” (needed to confirm everything I was saving in a big pile of internal objects was correct, as well as the first real verification of the RLE compression of 514×514 shape renderings.)
So that went well but boy, coding bogged down when I returned to “finishing” (at least enough) the compositeFile. Day after day with slow progress, but finally yesterday I got there. So I completed coding the integration yesterday with a very sketchy inspector. So today I reorganized the UI of the inspector and, very importantly, actually started showing thumbnails (128×128) in “album pages”, eventually with both a next/prev page working, but more usefully a cache of the thumbnails, after their first use.
I had no idea what to expect about performance. It’s unbelievable all the stuff that has to happen to get a thumbnail: 1) find all the blocks the blob is stored in in the composite file (with lots of verification nothing got broken), 2) copy data from blocks to an internal buffer (of variable size), 3) pass that data back to inspector, 4) who then restores the bitmap from the RLE (yet another copying of all the data), 5) then generates the thumbnail to display on the album page, and, 6) finally to cache the bitmaps so I don’t have to repeat all that when paging through the album to previously accessed pages. Fortunately generating a new page (18 shapes, 6 x 3 in a fairly big form and its picturebox) wasn’t that bad, about 3 seconds at fastest, 5 seconds to slowest, under a second when using the cache.
So the mechanism for recording history seems to work OK (I still don’t totally trust it, more testing will tell the whole story) and at least a simple way of finding the information again is available. The sequential browsing through album pages, however, is too slow and tedious to use once the history has thousands, even tens of thousands of shapes, but now that I have this much I can begin to focus on that problem, which was part of the point of this whole exercise.
So I’ve got a few things to do, at minimum:
- I have an important (but not critical) bug that I forgot to save the specific parameters in the <shape> node of my XML. I did save them in the <run> node, fortunately, but that requires some interpretation (human) to find the parameters for a particular shape when the run was iterating and generating more than one.
- to save a step I put the files (XML and the blobs) in a fixed location, which happens to be inside my Visual Studio project. Since I back that up frequently copying the (now) 82Meg blob file is bad. So I have a fairly simple plan to move them, but one more item to do.
- The blob file is designed to grow, as needed, but none of that is coded yet. There are two parts: a) extending the file when there is still space in the bitmap to account for the new blocks (my current file of about 20,000 blocks, only uses about half a bitmap), and, b) to extend even more starting chaining multiple bitmap blocks (somewhat tricky so probably a day to complete and thoroughly test especially as it takes a lot of data written to the file file before this even happens.
- And, oh yeah, forgot, I need to update the LastUpdatedDateTime in the header, a minor but useful nit.
- Then I really need to start adding things to the inspector:
- I built a “favorites” capability in the XML, so I need to be able to add a shape to the favorites, and once done, have a mode of generating album pages only for the favorites, plus show in the album pages of all shapes that a particular shape is also in favorites. This would be a critical thing on the path to a shape library.
- I already, mostly due to testing, have some duplicate shapes in the history. As I mentioned in a previous post automatically detecting duplicates is going to be really hard, so I have to do it manually. Deleting unneeded shapes (not actually delete in the XML, since this is “history”, but mark the XML that I deleted and discard the blob data so it can be reused).
- Then begin to experiment with alternate ways to churn through a lot of shapes efficiently, presumably some sort of manual rating and tagging to support search. This is part of the point of this POC, to explore how to get this to work well so I can have those features in the shape library itself.
- be able to do something when I click on a thumbnail in an album page, like: a) fetch its data back into shape generator to try more shapes, b) rerender the shapes, especially to a “path” which I’m just beginning to realize is the key thing I need in the shape compositor, and, c) whatever else I’ll think of as I actually try to use this thing.
Now this whole story doesn’t put up any pretty pictures on the screen for you to see but at least now I have a much better way to record those pretty pictures. I did a poor job of recording enough information in my OneNote log so I have some interesting shapes there I can’t figure out how to generate again (but now I can experiment with it, good old RSE) long enough to maybe stumble on them again.
And while grinding (and it has been a grind) on all this I keep thinking more and more about the shape compositor (which takes multiple simple shapes to make a more complicated one that probably can’t (certainly easily) be generated by the shape creator (it’s take it to generate lots of interesting simple shapes to use in more complex situations). And in the thinking I’m doing (much faster and wide ranging than trying to code the ideas I’ve already had) I realize this method of shape generator may not be sufficient so I’m thinking of how I might generate other types of shapes in yet another component.
So all this, shape generator shapes, composited shapes, and computed shapes is just to send enough stuff to the drawing composer, which is why I need the shape library and efficient access to it.
So despite hitting this major milestone I have a long way to go before I’ll be showing any of my generated mandalas (and giving them to you). But progress is progress and each time I get significant new functionality I usually think of even more things to do.
So stayed tuned, Dear Reader, this is all going somewhere, even with the gaps in my posting as I’m buried in 16 hour days turning ideas into working code.