The current codebase is a wee bit messy, things are confused. The rendering loop does filesystem operations and layout creation, both of which introduce drawing latency. And the renderer [DirStats] also does some UI logic, which makes things more confusing than they could be.
What I'd like to do is move all the blocking operations away from the rendering loop and do them in the background, making it possible to give a sort of limit for worst case performance. E.g. "I'm going to draw a maximum of 5000 rectangles per frame for this screen size and that takes 50 milliseconds. So if there's a free core available (set CPU affinity for bg threads different from rendering thread), the framerate should always be above 20 frames per second."
The road to a better design, something like this maybe?
FSCache -- filesystem model
- store files and directories
- store measurement info and sorted layouts
- do async traversal
- do async extra info fetches (thumbnails)
- fast lock-free read access
- manage watchers and invalidation
Implement by moving all FS-touching stuff, sorting and measuring from
DirStats to DirCache.
FSDraw -- renderer
- fetch data from FSCache and draw it to screen
- provide wanted draw depth information to UI
- provide click target information to UI
Implement by turning DirStats into a static class and splitting the drawing
process into a gathering pass and a drawing pass. The gathering pass is run
at UI action time and tells what the renderer would like to draw. The
drawing pass is independent and draws whatever info there is in the FSCache.
So there is a rendering traversal thread that does an explicit traversal of
the rendered part of the filesystem, and a drawing thread that draws the
current results of the traversal thread.
Filezoo -- user interface, controller
- all click action logic here
- guide traversal based on user actions
- call renderer when needed (expose, rendering traversal in progress)
- set up renderer drawing area transform
Main -- init, finalize
- load/save config and session data, parse command line options
- directory emblem patterns
- directory view settings
- ► 2013 (26)
- ► 2011 (20)
- ► 2010 (94)
- ► 2009 (84)
- Filezoo, day 18
- Filezoo, 17.3: image thumbnails
- Filezoo, 17.2: context menu, a bit nicer monitorin...
- Filezoo, 17.1: rewrite done-ish
- Filezoo, 16.1: rewrite, dev env screenie
- Filezoo, 15.2: DirStats static rewrite
- Filezoo, day 15: refactoring plan
- Yeah, it's going to be difficult
- Filezoo, day 14
- X application startup times
- More fishes
- Filezoo startup profile
- Filezoo, start of day 13: some timings, thumbnail ...
- Filezoo, day 12: zoom navigation
- Filezoo, day 11: silly icons, less traversal, pare...
- Filezoo, end of day 10 / start of day 11
- Filezoo, day 10 and 2/3: Manual rectangle clipping...
- Filezoo, end of day 9: requirements document, inte...
- Filezoo, start of day 9: more traversal banging, f...
- Filezoo, day 8: Merge of the recursive branch
- Filezoo, day 6
- Filezoo, end of day 5: Context-sensitive zoom, rec...
- Filezoo, start of day 5
- Filezoo, end of day 4: Speed!
- Filezoo: start of day 4
- A small shell script for Googling
- Filezoo, end of day 3: open terminal, threads
- Filezoo, start of day 3: zooming and panning
- Filezoo: end of day 2
- Filezoo: visual du with aspirations towards file m...
- Visual disk usage app using Mono
- A simple C# analog clock with Mono and Cairo
- Black on white desktop theme
- ▼ November (34)
- Filezoo - Minimalistic zoomable file manager
- Missile Fleet - A game written with Cake.js
- Gitbug - In-repo bug tracker for Git
- Prelude.ml - OCaml stdlib replacement with a Haskellish flavour
- Metadata - File metadata extraction tool and Ruby library
- Thumbnailer - File thumbnailing tool and Ruby library
- Random canvas demos