Hi John,
John <[EMAIL PROTECTED]> wrote on 03/04/2006 02:15:22 PM:
> On 3/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> You might consider holding these as totally separate 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.
You can do this, but I was actually thinking you could use the
hit-testing abilities of Batik to implement most of these tests in
which case you might never need to actually render these layers.
The hit testing will of course be slower than just looking up a
pixel in a bit map but depending on what the frequency of lookup is
this might not matter - I'm not sure there would be a significant
advantage over just loading a bitmap.
> > 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?
Most of the Batik internals always render as 32bit RGBA. However the
vector graphics don't really care. In this case you would/could do your
own
rendering to any type of buffer (8bit grey would likely work fine).
> 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. =)
I'm not 100% certain how well it will render to an 8bit pallete
buffer.
> 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.
Actually it does: java.awt.image.MultiPixelPackedSampleModel
I think with a pallete color model.
> 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
Sure packing stuff into bytes works. I'm not sure I would call this
an 'image' anymore (no drawing stuff is really going to work well). But
it may be a useful/compact datastructure to have this info on a dense
grid.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
