Hi John,
You might consider holding these as totally seperate SVG images
rather than viewing them as one multi-layer document. Otherwise you
will be turning on and off more stuff than you need too when you need to
'check' one of the non-visible layers (like foliage).
The second approach is to load these 'data layers' (as opposed to the visual layers) as raster images completely outside the SVG. This is the current approach I am leaning towards.
> 1920000 pixels in a 1600x1200 px map. Since the some layers are SVG
(text),
> they wont count pixel by pixel.
Right an SVG layer is essentially totally dependent on the complexity
of the geometry not the output size... until you render it.
Then it counts/calculates as a 32-bit raster? What does it 'become', in terms of the application calculations and allocation of memory? What I am curious about is whether restricting my SVG palette to 256 colors will help in memory requirements of the graphics component, or if it will not make a whit of difference if my SVG is composed of grayscale or 32-bit colors. =)
Some of this map data could ideally be held in 2-bit primitives (4 values is sufficient for foliage density, for instance) but Java has no such type available. I am currently pondering how to best represent this "little" data in a short, and am thinking that combining data into a single datum for each pixel, then splitting out that data for what I need, may be the way to go.
10100101 one pixel datum
^^--------- foliage depth/height
^^------- foliage density
^^----- terrain type (rough, clear)
^^--- water depth
Again, these are just ideas. Right now, I am just fiddling with ideas and approaches to the data, attempting to come up with a compact, memory-efficient design. In the end, all of the data 'layers' will be combined into a binary file with headers and additional information (signing, authorship, the SVG layers, the raster data layers). The application loader will split the data out as it needs it.
> Does Batik default all SVGs as a specific color depth (32-bit), or does
it
> dynamically examine the data and use memory based on what it finds?
For vector data it holds the fill (usually as an RGBA color with
floats) and the geometry to fill.
