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 André Ávila <as...@nextech.com.br> on 2006/03/17 20:56:35 UTC
Dealing with huge SVG files
Hello,
I need to deal with very big static SVG files (> 20MB). It is not a surprise that rendering such large files takes a long time and eats a lot of system resources. Therefore, I was wondering what would be the best way of dealing with this.
One idea I have is to break the huge SVG into smaller files (say, a 20MB SVG becomes 20 1MB files). Then, I would create multiple transparent canvases and render one on top of the other. This way the user wouldn't have to wait for the 20MB file to load. Is this a good solution? Can I have these transparent canvases?
Maybe someone has a better idea? What would be the best way to deal with such big files?
André
Re: Dealing with huge SVG files
Posted by mikael-aronsson <mi...@telia.com>.
Most of the time will be spent processing the DOM before you can display anything so it would be difficult to support progressive rendering as some parts needed to start the rendering may be at the end of the document for example.
You could generate a simplified SVG of each big one that is small without details that you load first and display and at the same time start to load the big one in the background and simply replace the simplified one with the more complex when it is loaded, if the SVG files are static that could be a possible solution maybe.
But as I said, you should try first because the DOM tree in memory will be huge.....
Mikael
----- Original Message -----
From: André Ávila
To: batik-users@xmlgraphics.apache.org
Sent: Saturday, March 18, 2006 1:38 AM
Subject: Re: Dealing with huge SVG files
Hello Mikael,
We are not creating the SVGs, so there's not much to do regarding that. Actually the files are filled with tiny little details that I doubt the user would want removed, althouigh we have suggested that as a partial solution. However our feeling is that, unless the SVGs are reduced to something like 1/10th of the original file, they are still going to be quite heavy on Batik.
I read something about progressive rendering that might help to alleviate the rendering time for large documents. Does Batik support that?
Actually I don't have any of those files to test yet, so I wonder if Batik will be able to render them at all.
Many thanks for your time. If you have any other ideas, please let me know.
----- Original Message -----
From: mikael-aronsson
To: batik-users@xmlgraphics.apache.org
Sent: Friday, March 17, 2006 5:00 PM
Subject: Re: Dealing with huge SVG files
Hi !
A 20MB SVG file must create a gigantic DOM structure that would eat tons of memory, isn't there any possibility to cut down on the size of the files ? there must be alot of information that will not be visible anyway unless you zoom in a lot or something like that ?
In theory I assume it would be possible to put a top layer on a transparent canvas on top but I think it would be tricky to make it work smooth.
Mikael
----- Original Message -----
From: André Ávila
To: batik-users@xmlgraphics.apache.org
Sent: Friday, March 17, 2006 8:56 PM
Subject: Dealing with huge SVG files
Hello,
I need to deal with very big static SVG files (> 20MB). It is not a surprise that rendering such large files takes a long time and eats a lot of system resources. Therefore, I was wondering what would be the best way of dealing with this.
One idea I have is to break the huge SVG into smaller files (say, a 20MB SVG becomes 20 1MB files). Then, I would create multiple transparent canvases and render one on top of the other. This way the user wouldn't have to wait for the 20MB file to load. Is this a good solution? Can I have these transparent canvases?
Maybe someone has a better idea? What would be the best way to deal with such big files?
André
Re: Dealing with huge SVG files
Posted by André Ávila <as...@nextech.com.br>.
Thanks a lot Thomas. I thought this was a lost cause, but after reading this
it feels like there's a tiny light at the end of the tunnel. :)
I will try to work on your ideas and see what I can come up with.
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Friday, March 17, 2006 9:49 PM
Subject: Re: Dealing with huge SVG files
> Hi André,
>
> You mentioned that the files are static. If so you might consider
> building the GVT tree and
> then using the JGVTComponent. This would allow you to dispose of the DOM
> entirely.
>
> André Ávila <as...@nextech.com.br> wrote on 03/17/2006 07:38:24 PM:
>
> > I read something about progressive rendering that might help to
> alleviate the
> > rendering time for large documents. Does Batik support that?
>
> You can turn on 'progressive rendering' in the Canvas turn off
> double buffering first. This will help if the actual painting takes a
> long time but probably much of the time will go into parsing the XML
> and building the GVT tree.
>
> > Actually I don't have any of those files to test yet, so I wonder if
> Batik
> > will be able to render them at all.
>
> I wonder as well, a 20MB SVG is very large you will need to set the
> heap high.
>
> > One idea I have is to break the huge SVG into smaller files (say, a 20MB
> SVG
> > becomes 20 1MB files). Then, I would create multiple transparent
> canvases and
> > render one on top of the other. This way the user wouldn't have to wait
> for
> > the 20MB file to load. Is this a good solution? Can I have these
> transparent canvases?
>
> This is an option, keeping them in sync may be a bit of work however.
>
>
> > Maybe someone has a better idea? What would be the best way to deal with
> such big files?
>
> You could also read them one at a time and append the generated GVT
> tree's
> to the first GVT tree (this would be tricker to do with SVG, and would
> require
> the Document to be dynamic which might not be ideal, as dynamic documents
> require
> more memory).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Dealing with huge SVG files
Posted by th...@kodak.com.
Hi André,
You mentioned that the files are static. If so you might consider
building the GVT tree and
then using the JGVTComponent. This would allow you to dispose of the DOM
entirely.
André Ávila <as...@nextech.com.br> wrote on 03/17/2006 07:38:24 PM:
> I read something about progressive rendering that might help to
alleviate the
> rendering time for large documents. Does Batik support that?
You can turn on 'progressive rendering' in the Canvas turn off
double buffering first. This will help if the actual painting takes a
long time but probably much of the time will go into parsing the XML
and building the GVT tree.
> Actually I don't have any of those files to test yet, so I wonder if
Batik
> will be able to render them at all.
I wonder as well, a 20MB SVG is very large you will need to set the
heap high.
> One idea I have is to break the huge SVG into smaller files (say, a 20MB
SVG
> becomes 20 1MB files). Then, I would create multiple transparent
canvases and
> render one on top of the other. This way the user wouldn't have to wait
for
> the 20MB file to load. Is this a good solution? Can I have these
transparent canvases?
This is an option, keeping them in sync may be a bit of work however.
> Maybe someone has a better idea? What would be the best way to deal with
such big files?
You could also read them one at a time and append the generated GVT
tree's
to the first GVT tree (this would be tricker to do with SVG, and would
require
the Document to be dynamic which might not be ideal, as dynamic documents
require
more memory).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Dealing with huge SVG files
Posted by André Ávila <as...@nextech.com.br>.
Hello Mikael,
We are not creating the SVGs, so there's not much to do regarding that. Actually the files are filled with tiny little details that I doubt the user would want removed, althouigh we have suggested that as a partial solution. However our feeling is that, unless the SVGs are reduced to something like 1/10th of the original file, they are still going to be quite heavy on Batik.
I read something about progressive rendering that might help to alleviate the rendering time for large documents. Does Batik support that?
Actually I don't have any of those files to test yet, so I wonder if Batik will be able to render them at all.
Many thanks for your time. If you have any other ideas, please let me know.
----- Original Message -----
From: mikael-aronsson
To: batik-users@xmlgraphics.apache.org
Sent: Friday, March 17, 2006 5:00 PM
Subject: Re: Dealing with huge SVG files
Hi !
A 20MB SVG file must create a gigantic DOM structure that would eat tons of memory, isn't there any possibility to cut down on the size of the files ? there must be alot of information that will not be visible anyway unless you zoom in a lot or something like that ?
In theory I assume it would be possible to put a top layer on a transparent canvas on top but I think it would be tricky to make it work smooth.
Mikael
----- Original Message -----
From: André Ávila
To: batik-users@xmlgraphics.apache.org
Sent: Friday, March 17, 2006 8:56 PM
Subject: Dealing with huge SVG files
Hello,
I need to deal with very big static SVG files (> 20MB). It is not a surprise that rendering such large files takes a long time and eats a lot of system resources. Therefore, I was wondering what would be the best way of dealing with this.
One idea I have is to break the huge SVG into smaller files (say, a 20MB SVG becomes 20 1MB files). Then, I would create multiple transparent canvases and render one on top of the other. This way the user wouldn't have to wait for the 20MB file to load. Is this a good solution? Can I have these transparent canvases?
Maybe someone has a better idea? What would be the best way to deal with such big files?
André
Re: Dealing with huge SVG files
Posted by mikael-aronsson <mi...@telia.com>.
Hi !
A 20MB SVG file must create a gigantic DOM structure that would eat tons of memory, isn't there any possibility to cut down on the size of the files ? there must be alot of information that will not be visible anyway unless you zoom in a lot or something like that ?
In theory I assume it would be possible to put a top layer on a transparent canvas on top but I think it would be tricky to make it work smooth.
Mikael
----- Original Message -----
From: André Ávila
To: batik-users@xmlgraphics.apache.org
Sent: Friday, March 17, 2006 8:56 PM
Subject: Dealing with huge SVG files
Hello,
I need to deal with very big static SVG files (> 20MB). It is not a surprise that rendering such large files takes a long time and eats a lot of system resources. Therefore, I was wondering what would be the best way of dealing with this.
One idea I have is to break the huge SVG into smaller files (say, a 20MB SVG becomes 20 1MB files). Then, I would create multiple transparent canvases and render one on top of the other. This way the user wouldn't have to wait for the 20MB file to load. Is this a good solution? Can I have these transparent canvases?
Maybe someone has a better idea? What would be the best way to deal with such big files?
André