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 Sheetal Madasnal <sm...@rediffmail.com> on 2001/06/18 19:12:30 UTC

Modified SVG DOM does not get repainted in Netscape on Solaris

Hi,

 I am using the 1.0 release of Batik SVG api. I have a class extending the JSVGComponent and successful in modifying properties of some dom elements and getting it rendered on the canvas. Using the setSVGDocument() after modifying the current svgDocument.
 
 This works perfectly on Windows browsers IE5.5, Netscape 4.7 (with the Java 1.3 plugin). But Netscape 4.76 on Solaris is a total mess. It does not repaint the applet after the DOM is modified and the setSVGDocument() is called.

 I have tried calling invalidate(), validate(), repaint(), immediateRepaint() and they don't work.

 Is this related to the doublebuffering and or the progressive paint thread being used in the JSVGComponent?

 I have set doublebufferedrendering and progressivepaint to false but this does not help either.

 any clues?

thanks in advance,
-sheetal

 



_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




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


Re: Modified SVG DOM does not get repainted in Netscape on Solaris

Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <tk...@sophia.inria.fr> writes:

TK> On Monday 18 June 2001 19:12, Sheetal Madasnal wrote:

>> This works perfectly on Windows browsers IE5.5, Netscape 4.7 (with
>> the Java 1.3 plugin). But Netscape 4.76 on Solaris is a total
>> mess. It does not repaint the applet after the DOM is modified and
>> the setSVGDocument() is called.

TK> I have no idea, sorry.  May be thomas who is working on solaris
TK> may have one...

    Well, you don't specify what version of Solaris, but early
versions of Solaris (2.5.x at least) had serious redraw problems with
the Java 2 JVM's (the only approved JVM was a particular build of 1.2.2).

    However, as I recall JDK 1.3 would refuse to run on this version
of Solaris.  Are you also using the 1.3 plugin on Solaris?

    Does the Batik svgbrowser work correctly on the same Solaris Box?

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


Re: Modified SVG DOM does not get repainted in Netscape on Solaris

Posted by Thierry Kormann <tk...@sophia.inria.fr>.
On Monday 18 June 2001 19:12, Sheetal Madasnal wrote:
> Hi,
>
>  I am using the 1.0 release of Batik SVG api. I have a class extending the
> JSVGComponent and successful in modifying properties of some dom elements
> and getting it rendered on the canvas. Using the setSVGDocument() after
> modifying the current svgDocument.
>
>  This works perfectly on Windows browsers IE5.5, Netscape 4.7 (with the
> Java 1.3 plugin). But Netscape 4.76 on Solaris is a total mess. It does not
> repaint the applet after the DOM is modified and the setSVGDocument() is
> called.
>
>  I have tried calling invalidate(), validate(), repaint(),
> immediateRepaint() and they don't work.
>
>  Is this related to the doublebuffering and or the progressive paint thread
> being used in the JSVGComponent?
>
>  I have set doublebufferedrendering and progressivepaint to false but this
> does not help either.

I have no idea, sorry.
May be thomas who is working on solaris may have one...

Thierry.


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