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: [email protected]
For additional commands, e-mail: [email protected]
