xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frederik Santens" <frederik.sant...@pandora.be>
Subject RE: Zoomwindow on SVGCanvas
Date Thu, 02 Sep 2004 22:46:27 GMT
Hi,

Is there already support in batik to share the same GVT tree
(GraphicsNode I guess) among multiple canvasses? If not, any clous on
how to do it. 

Thx
Frederik



-----Original Message-----
From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
Sent: donderdag 26 augustus 2004 23:22
To: Batik Users
Subject: Re: Zoomwindow on SVGCanvas

Frederik Santens wrote:

> I want to do automatic updates via the update manager in both the
> zoomwindow as in the application window. Can I do this in 1 step or do
I
> have to perform the update (dom manipulation) in both updatemanagers
of
> the JSVGCanvas of the application window and the one of the
zoomwindow?

    It depends on how you set things up.  If you just have two
JSVGCanvas windows then you should have two totally independent
documents and  you would have to update both documents.  If you set it
up so the zoom window uses the same GVT tree as the overview then just
updating the overview will update the rendering tree used by the zoom
window, although currently only the overview window will get the
needed  repaint requests.  You would either have to extend the
UpdateManager to trigger updates in multiple destinations, or perhaps
just repaint the entire zoom window.

    Sorry, but you are working at the edges of what Batik supports.  I
think what you are doing is interesting and useful to support but it
isn't quite there yet.  I hope you will consider working on these
issues and contributing back.

> 
> Frederik
> 
> -----Original Message-----
> From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
> Sent: donderdag 26 augustus 2004 12:01
> To: Batik Users
> Subject: Re: Zoomwindow on SVGCanvas
> 
> Hi Frederik,
> 
>     The core components of Batik don't care if the output is buffered,
> however the Swing components are pretty well embedded with the notion
> of having an offscreen buffer that they can use to update the screen
> quickly.  There is no real reason you couldn't change this although
> it would be a non-trivial piece of work.
> 
> Frederik Santens wrote:
> 
>>So , the only solution is more memory (since I already tried -Xmx). 
>>There is no way to tell batik to paint the svg without buffering the 
>>whole thing?
>>
>>thx
>>Frederik
>>
>>At 02:50 26/08/2004, you wrote:
>>
>>
>>>Frederik Santens wrote:
>>>
>>>
>>>>We also need to render the svg of the main application on a screen
> 
> of 30
> 
>>>>metres.
>>>
>>>
>>>  Can I watch movies at your house :)
>>>
>>>
>>>>When I render an svg on a jpanel of 5000 pixel I already get a
>>>>OutofMemory exception. Is this normal?
>>>
>>>
>>>   Probably, Batik creates an offscreen buffer that it renders into.
>>>The default partition for a Java Virtual machine is pretty paltry so
>>>unless you are already using the -Xmx option to increase the max
>>>memory Batik will allocate I would expect such a window to run out of
>>>memory.
>>>
>>>
>>>>-----Original Message-----
>>>>From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] Sent:
> 
> zaterdag 
> 
>>>>21 augustus 2004 2:24
>>>>To: Batik Users
>>>>Subject: Re: Zoomwindow on SVGCanvas
>>>>Hi Frederik,
>>>>    I don't there is an easy way to achieve this.  Depending on how
>>>>much you expect to pan around the document you might consider
>>>>rendering the whole document once at the higher resolution and
>>>>downsampling for the 'overview' display.
>>>>    My suspicion is that they just re-render the portion under
>>>>the 'magnifier'.  You should be able to set things up so that
>>>>the two windows use the same GVT tree which would save you the
>>>>memory overhead of having two copies of the document in
>>>>memory.  You can look at the Thumbnail stuff in squiggle for
>>>>an example.
>>>>frederik.santens@pandora.be wrote:
>>>>
>>>>
>>>>>We have a main application that renders a SVG. We also have to
> 
> create
> 
>>>>a zoomwindow on that rendered svg in the main application window.
> 
> This
> 
>>>>zoomwindow is a floating window. The zoomwindow enlarges the area
> 
> around
> 
>>>>the mouse pointer on the main window.
>>>>
>>>>
>>>>>The functionality is more or less the same as in the DWG Viewer
>>>>>"Free DWG Viewer from Brava!"
>>>>
>>>>(http://www.infograph.com/products/dwgviewer/)
>>>>
>>>>
>>>>>How could we do this without rendering the svg 2 times?
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>  
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
>  
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.740 / Virus Database: 494 - Release Date: 16/08/2004
 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message