art with code

2008-12-10

Filezoo, day 30-ish: painted myself in a corner

Ok, committed a few bugfixes to the traversal code, and now the size totals work pretty nicely, though likely allocate way too much. A bigger problem is that the current FSCache design is suffering from a couple decisions made at last rewrite time. In particular, the drawing model uses the FSCache directly, which means that it's race-condition-prone. If a filesystem change happens during drawing a frame, what gets drawn beyond that point is anyone's guess. It'll be fixed by the next frame though.

The New And Improved Design Suffering From Version 2 Syndrome I have is to split the FSCache into three caches instead of the current two: Entry, Thumbnail -> Entry, StatInfo, Thumbnail. The idea being that Entry would be a very light-weight thing used by the recursive traversal, and StatInfo contains all the stat struct information. StatInfo cache and Thumbnail cache would have LRU expiration to limit memory use. The Entry cache wouldn't really need expiration, as it's not going to be much larger than 20 megs (but it is a possible memory leak...)

Then the drawing model builder wouldn't use the FSCache directly, but build a temporary drawing tree that's always ready to draw. Currently you can get drawing flicker on filesystem changes and traversal changes because the changes set ReadyToDraw = false for that part of the tree, and the model builder needs to revisit and redo the layout to make it drawable again.

Building a drawing tree separate from the FSCache would allow propagating the FSCache changes to the drawing model in a controlled manner, so that the tree is always in a drawable state and there's no flicker and you can't have race conditions involving filesystem changes and the drawing thread.

Why the new design suffers from V2S is that it requires a well-nigh complete rewrite of the cache behaviour and the draw model building behaviour. Yesterday I wrote a few hundred lines of code in an effort to do the split, but as I didn't do it by small compilable changes, it very quickly veered into the "I'm never going to get this to work"-state of lost confidence. Lesson learned once again.

So. Stashed the changes in a branch, forked a new branch from master and backported some of the small changes back. I also fixed some buggy behaviour, now filesystem changes aren't as likely to hose the drawn state and UTF-8 filenames are handled correctly by traversal (yay for new System.Text.UTF8Encoding().GetString(byte[]).) I think I'll spend the rest of the day doing something with a high return on investment, a.k.a. UI work.

Then piecemeal porting of FSCache over to a cleaner system? Don't break the build!

No comments:

Blog Archive