binary XML ?

[Andrew Neiderer]

I am sort of new to XML and SVG. So if this has been addressed before please
be patient and/or just point me to a URL.

I have written a Java application which generates lots (150 x 150)
of Scaleable Vector Graphics (SVG), which is a 2D XML application, <rect>s.
The problem is that it takes about 10 seconds to display the frame. I need
to approach real-time display if possible. So I thought a binary representation
of the data would speed it up.

Is binary XML a possibility, or should I not use an XML approach. Maybe it
doesn't even make sense and I should avoid SVG.

Any advice is appreciated.

Thank you.

- Andrew M. Neiderer

 

[=?ISO-8859-1?Q?J=FCrgen_Kahrs?=]

I have written a Java application which generates lots (150 x 150)
of Scaleable Vector Graphics (SVG), which is a 2D XML application, <rect>s.
The problem is that it takes about 10 seconds to display the frame. I need
to approach real-time display if possible. So I thought a binary representation
of the data would speed it up.

Do you really think that the XML representation of your
data is responsible for the slow display ? I would rather
guess that your Java implementation of the display is to
be blamed.

Is binary XML a possibility, or should I not use an XML approach. Maybe it
doesn't even make sense and I should avoid SVG.

Binary XML has been talked about several times here.
It looks like Microsoft will set a standard for storing
XML binarily when their new MS Word application is released.
Remember that uncompressing a binary needs even more time.

I bet that the bottleneck in your application is SVG,
its interpretation and the rest of the display process.

 

[Gale]

I am sort of new to XML and SVG. So if this has been addressed before please
be patient and/or just point me to a URL.

I have written a Java application which generates lots (150 x 150)
of Scaleable Vector Graphics (SVG), which is a 2D XML application, <rect>s.
The problem is that it takes about 10 seconds to display the frame. I need
to approach real-time display if possible. So I thought a binary representation
of the data would speed it up.

Is binary XML a possibility, or should I not use an XML approach. Maybe it
doesn't even make sense and I should avoid SVG.

Any advice is appreciated.

Thank you.

- Andrew M. Neiderer

you can't insert binary data in xml file, but you can define extern
Entity, or you can use Unicode to encode the data and insert it directly
to xml (you could find some problems if you use schema)

 

[alan]

I am sort of new to XML and SVG. So if this has been addressed before please
be patient and/or just point me to a URL.

I have written a Java application which generates lots (150 x 150) of
Scaleable Vector Graphics (SVG), which is a 2D XML application, <rect>s.
The problem is that it takes about 10 seconds to display the frame. I need
to approach real-time display if possible. So I thought a binary
representation of the data would speed it up.

Is binary XML a possibility, or should I not use an XML approach. Maybe it
doesn't even make sense and I should avoid SVG.

SVG is still early, but...

Did you do an profiling? Are you assuming that the delay is in the XML
parser?

 

[Peter Flynn]

I am sort of new to XML and SVG. So if this has been addressed before
please
be patient and/or just point me to a URL.

I have written a Java application which generates lots (150 x 150)
of Scaleable Vector Graphics (SVG), which is a 2D XML application,
<rect>s.
The problem is that it takes about 10 seconds to display the frame. I
need
to approach real-time display if possible. So I thought a binary
representation of the data would speed it up.

Is binary XML a possibility, or should I not use an XML approach. Maybe
it doesn't even make sense and I should avoid SVG.

Binary XML comes up from time to time and the answer is in the FAQ at
http://xml.silmaril.ie/authors/graphics/

* XML is a text format, so you can't embed raw binary in it. Period.

* You *could* embed it in some coded format, eg Base64 or UUencode,
but there would be a processing overhead to decode it.

* You *can* zip up a whole file (ie compress for transmission) if
you know that your readers are equipped to unzip it the other end.
(For example, OpenOffice already stores its documents as zipped XML.)

///Peter

 

[Jaco]

Andrew Neiderer wrote:




Binary XML comes up from time to time and the answer is in the FAQ at
http://xml.silmaril.ie/authors/graphics/

* XML is a text format, so you can't embed raw binary in it. Period.

* You *could* embed it in some coded format, eg Base64 or UUencode,
but there would be a processing overhead to decode it.

* You *can* zip up a whole file (ie compress for transmission) if
you know that your readers are equipped to unzip it the other end.
(For example, OpenOffice already stores its documents as zipped XML.)

///Peter

It would be nice if there was an API for reading directly from zipped
XML files without needing to unzip first. That could be even faster than
reading from uncompressed XML files.

 

[Gerald Aichholzer]

Andrew Neiderer wrote:

[...]

Is binary XML a possibility, or should I not use an XML approach. Maybe
it doesn't even make sense and I should avoid SVG.

Binary XML comes up from time to time and the answer is in the FAQ at
http://xml.silmaril.ie/authors/graphics/

[...]

* You *can* zip up a whole file (ie compress for transmission) if
you know that your readers are equipped to unzip it the other end.
(For example, OpenOffice already stores its documents as zipped XML.)

It would be nice if there was an API for reading directly from zipped
XML files without needing to unzip first. That could be even faster than
reading from uncompressed XML files.

I'm not quite sure, but AFAIR zip cannot be streamed. You need
the whole file to be able to decompress the data. This is the
reason why webservers use gzip for compressing HTML-pages on
the fly.

Gerald

 

[nicolas]

Le Fri, 12 Aug 2005 20:44:28 +0200

Do you really think that the XML representation of your
data is responsible for the slow display ? I would rather
guess that your Java implementation of the display is to
be blamed.

Maybe batik library is fast enough?
http://xml.apache.org/batik/index.html

 

[Steve Jorgensen]

Andrew Neiderer wrote:


[...]

Is binary XML a possibility, or should I not use an XML approach. Maybe
it doesn't even make sense and I should avoid SVG.


Binary XML comes up from time to time and the answer is in the FAQ at
http://xml.silmaril.ie/authors/graphics/

[...]

* You *can* zip up a whole file (ie compress for transmission) if
you know that your readers are equipped to unzip it the other end.
(For example, OpenOffice already stores its documents as zipped XML.)

It would be nice if there was an API for reading directly from zipped
XML files without needing to unzip first. That could be even faster than
reading from uncompressed XML files.

I'm not quite sure, but AFAIR zip cannot be streamed. You need
the whole file to be able to decompress the data. This is the
reason why webservers use gzip for compressing HTML-pages on
the fly.

From what I've read of compression algorithms, I think that's not true. Worst
case, you need one whole block of a file before you can decompress that block,
but I don't think you ever need a whole large file before you start
decompressing.

 

[Gerald Aichholzer]

From what I've read of compression algorithms, I think that's not true. Worst
case, you need one whole block of a file before you can decompress that block,
but I don't think you ever need a whole large file before you start
decompressing.

Well, I'm no expert, but HTTP supports several compression methods
(see [1]). Why ZIP is not among the supported algorithms I don't
know exactly. I thought it is because ZIP can't be uncompressed
before the whole file is transferred. This would be a major dis-
advantage when rendering HTML files.

Gerald

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html

 

[Peter Flynn]

From what I've read of compression algorithms, I think that's not true.
Worst case, you need one whole block of a file before you can decompress
that block, but I don't think you ever need a whole large file before you
start decompressing.

Well, I'm no expert, but HTTP supports several compression methods
(see [1]). Why ZIP is not among the supported algorithms I don't
know exactly. I thought it is because ZIP can't be uncompressed
before the whole file is transferred. This would be a major dis-
advantage when rendering HTML files.

-- AFAIK Gerald is right: the ZIP format writes its directory at the end
of the file, so you have to have the whole file before you can unpack
it. This is why unzipping multi-floppy ZIP files required you to put
in the last disk of the set before they could start work.

///Peter

 

[Steve Jorgensen]

On Wed, 17 Aug 2005 22:08:38 +0200, Gerald Aichholzer


I'm not quite sure, but AFAIR zip cannot be streamed. You need
the whole file to be able to decompress the data. This is the
reason why webservers use gzip for compressing HTML-pages on
the fly.


From what I've read of compression algorithms, I think that's not true.
Worst case, you need one whole block of a file before you can decompress
that block, but I don't think you ever need a whole large file before you
start decompressing.

Well, I'm no expert, but HTTP supports several compression methods
(see [1]). Why ZIP is not among the supported algorithms I don't
know exactly. I thought it is because ZIP can't be uncompressed
before the whole file is transferred. This would be a major dis-
advantage when rendering HTML files.

-- AFAIK Gerald is right: the ZIP format writes its directory at the end
of the file, so you have to have the whole file before you can unpack
it. This is why unzipping multi-floppy ZIP files required you to put
in the last disk of the set before they could start work.

///Peter

Well, you're absolutely right. I was reading ZIP, but I was thinking gzip
while I was reading it. gzip is a compression format that -is- intended for
use with streams, and is widely available.