You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by John <bl...@gmail.com> on 2006/03/03 16:46:51 UTC
Memory reqs of an SVG?
On the train into work this morning, I was working on a project idea. The
idea is a multi-layered map in SVG for a wargame. Now, the various layers
are primarily meant for segregation of data, by purpose, in memory. For
instance, a height map layer that contains data showing topographic heights;
another map that dictates foliage layer and density, etc. The purpose of
layering is to allow the map to toggle visibility of the layer (using <g>
element grouping) and limit the amount of data that the engine will have to
search to resolve a data check (so it only searches the Foliage layer, and
not the height map, for foliage density checks).
Layers of Map
Layer numbers are numbered from 0 upwards, so higher numbered layers are
above, or painted later than, the lower numbered layers.
# Vis? Usage and
notes
Bits
Style
0 Y Topographic visual
map
32
SVG
1 N Height map
(256g)
8
BMP
2 Y Water visual
map
8 SVG
3 N Water depth map (256g) boolean subtracted from
topographic height map 8 BMP
4 Y Manmade visual map roads, buildings, bridges,
constructions 2 SVG
5 Y Foliage visual
map
8 SVG
6 N Foliage depth map (256g) boolean added to topographic
height map 8 BMP
7 Y Element plotting
layer
8 SVG
8 Y Effects plotting layer smoke,
light 16 SVG ?
9 Y Overlay plotting layer planning
overlays 8 SVG
10 Y Grid
lines
8 SVG
1920000 pixels in a 1600x1200 px map. Since the some layers are SVG (text),
they wont count pixel by pixel.
Now, my question is this: For the SVG layers, does the color depth impact
the memory requirements for that 'layer' at all? 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?
Would a black and white (2-bit) SVG of text take less memory than an
identical 32-bit color SVG of the same node/shape/glyph data?
Re: Memory reqs of an SVG?
Posted by th...@kodak.com.
Hi John,
John <bl...@gmail.com> wrote on 03/04/2006 02:15:22 PM:
> On 3/4/06, thomas.deweese@kodak.com <th...@kodak.com> 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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Memory reqs of an SVG?
Posted by John <bl...@gmail.com>.
On 3/4/06, thomas.deweese@kodak.com <th...@kodak.com> wrote:
>
> 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.
>
>
Re: Memory reqs of an SVG?
Posted by th...@kodak.com.
Hi John,
John <bl...@gmail.com> wrote on 03/03/2006 10:46:51 AM:
> On the train into work this morning, I was working on a project idea.
The
> idea is a multi-layered map in SVG for a wargame. Now, the various
layers are
> primarily meant for segregation of data, by purpose, in memory. For
instance,
> a height map layer that contains data showing topographic heights;
another map
> that dictates foliage layer and density, etc. The purpose of layering
is to
> allow the map to toggle visibility of the layer (using <g> element
grouping)
> and limit the amount of data that the engine will have to search to
resolve a
> data check (so it only searches the Foliage layer, and not the height
map, for
> foliage density checks).
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).
> 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.
> Now, my question is this: For the SVG layers, does the color depth
impact the
> memory requirements for that 'layer' at all?
Not until you ask to render 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.
> Would a black and white (2-bit) SVG of text take less memory than an
identical
> 32-bit color SVG of the same node/shape/glyph data?
No.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org