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 oroadfc <or...@hotmail.com> on 2009/09/08 23:10:51 UTC
Different behaviour of SVGGraphics2D with same program on similar
machines
Hi, weird problem here
I'm using batik's SVGGraphics2D class to produce a svg screen capture of my
java app on one machine (standard win xp box) and it produces a svg file
full of vectors as hoped...
But try the same program, same batik version, same java version (1.6) on my
home machine (standard win xp box again) and it outputs one big bitmap blob
to the svg file...
both the graphics cards are nvidia's, the java versions are both 1.6.10+,
identical batik libraries, identical programs.
What could cause this?
--
View this message in context: http://www.nabble.com/Different-behaviour-of-SVGGraphics2D-with-same-program-on-similar-machines-tp25354283p25354283.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Different behaviour of SVGGraphics2D with same program on similar
machines
Posted by Helder Magalhães <he...@gmail.com>.
Hi oroadfc,
> But try the same program, same batik version, same java version (1.6) on my
> home machine (standard win xp box again) and it outputs one big bitmap blob
> to the svg file...
You don't state which Batik version this occurred in! Also without at
least a screenshot of the problem it's really hard to guess on what's
happening... Right? ;-)
Also, you haven't stated if this is reproducible every time or
sometimes, attach a test case, etc....
Please consider reading a bit on how to better report issues [1]. :-)
> What could cause this?
A shoot in the dark makes me suggest you double check versions:
* Batik's;
* Java ("1.6" for itself is not enough, the full output of 'java
-version' can be useful; mine is "1.6.0_16", for example);
* Graphics adapter driver (can be checked in "Control Panel",
"System" option, "Hardware" tab, "Device Manager" button and crawling
to the "Display adapters" sub-tree, right click on the graphics
adapter and choose "Properties", "Driver" tab);
Hope this helps,
Helder
[1] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Different behaviour of SVGGraphics2D with same program on
similar machines
Posted by oroadfc <or...@hotmail.com>.
oroadfc wrote:
>
>
> thomas.deweese wrote:
>>
>> Typically if you get a bitmap blob that means that you are 'recording'
>> Swing's offscreen bitmap cache. You can turn that off in Swing
>> (JComponent.setDoubleBuffered). I think there is some sort of
>> heuristic around when/if Swing decides to use double buffering.
>>
>> I'd also suggest you use batik.svggen.SwingSVGPrettyPrint to do this
>> since it will take care of issues like the above for you.
>>
>
> Thanks for the hint, it sounds plausible as everything between the
> machines in java + code terms is identical, I'll try it out later by
> disabling double buffering
>
> I've tried the SwingSVGPrettyPrint, the thing is on a Window object I can
> call w.paint (SVGGraphics2D) and get the whole shebang (including menu
> bar, and window decorations if I've enabled lookandfeel based JFrame
> decorations) - whereas SwingSVGPrettyPrint demands JComponents which don't
> appear until below a frame's ContentPane container (and if that holds
> multiple JComponents as direct children you have to draw chunks of the
> interface separately as well)
>
Yup, you were on the money
RepaintManager currentManager =
RepaintManager.currentManager(w);
boolean dBufferOn = currentManager.isDoubleBufferingEnabled();
currentManager.setDoubleBufferingEnabled(false);
w.paint (svgGenerator);
currentManager.setDoubleBufferingEnabled (dBufferOn);
wrapping a change in the repaintmanager double buffering strategy round my
paint call has solved this
Thanks!
--
View this message in context: http://www.nabble.com/Different-behaviour-of-SVGGraphics2D-with-same-program-on-similar-machines-tp25354283p25371917.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Different behaviour of SVGGraphics2D with same program on
similar machines
Posted by oroadfc <or...@hotmail.com>.
thomas.deweese wrote:
>
> Typically if you get a bitmap blob that means that you are 'recording'
> Swing's offscreen bitmap cache. You can turn that off in Swing
> (JComponent.setDoubleBuffered). I think there is some sort of
> heuristic around when/if Swing decides to use double buffering.
>
> I'd also suggest you use batik.svggen.SwingSVGPrettyPrint to do this
> since it will take care of issues like the above for you.
>
Thanks for the hint, it sounds plausible as everything between the machines
in java + code terms is identical, I'll try it out later by disabling double
buffering
I've tried the SwingSVGPrettyPrint, the thing is on a Window object I can
call w.paint (SVGGraphics2D) and get the whole shebang (including menu bar,
and window decorations if I've enabled lookandfeel based JFrame decorations)
- whereas SwingSVGPrettyPrint demands JComponents which don't appear until
below a frame's ContentPane container (and if that holds multiple
JComponents as direct children you have to draw chunks of the interface
separately as well)
--
View this message in context: http://www.nabble.com/Different-behaviour-of-SVGGraphics2D-with-same-program-on-similar-machines-tp25354283p25368210.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Different behaviour of SVGGraphics2D with same program on similar
machines
Posted by th...@kodak.com.
Hi Oroadfc,
oroadfc <or...@hotmail.com> wrote on 09/08/2009 05:10:51 PM:
> I'm using batik's SVGGraphics2D class to produce a svg screen capture of
my
> java app on one machine (standard win xp box) and it produces a svg file
> full of vectors as hoped...
>
> But try the same program, same batik version, same java version (1.6) on
my
> home machine (standard win xp box again) and it outputs one big bitmap
blob
> to the svg file...
Typically if you get a bitmap blob that means that you are 'recording'
Swing's offscreen bitmap cache. You can turn that off in Swing
(JComponent.setDoubleBuffered). I think there is some sort of
heuristic around when/if Swing decides to use double buffering.
I'd also suggest you use batik.svggen.SwingSVGPrettyPrint to do this
since it will take care of issues like the above for you.
> both the graphics cards are nvidia's, the java versions are both
1.6.10+,
> identical batik libraries, identical programs.