[kepler-dev] question about Diva's JCanvas
Christopher Brooks
cxh at eecs.berkeley.edu
Wed Mar 12 20:20:34 PDT 2008
Hi Ian,
Interesting!
I started looking into this. The double buffering code has
been in diva.canvas.JCanvas since June, 1998.
http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.4.4
says:
2.4.4 Swing's true double buffering
Swing's true double buffering has now been enabled. Swing used to
provide double buffering on an application basis, it now provides it
on a per-window basis and native exposed events are copied directly
from the double buffer. This significantly improves Swing performance,
especially on remote servers.
Please see the Scott Violet's Blog for full details.
http://weblogs.java.net/blog/zixle/archive/2005/04/no_more_gray_re_1.html
There is a bug that says this is fixed in Java 1.6:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4967886
I looked around and I can't be sure exactly when the Java release
changed. The Java release notes for 1.5 and 1.6 are not much help.
I'm just curious, do you have a reference for when the double
buffering changed?
We are still supporing Java 1.5, so we might need to conditionalize
this.
Putting a println statement before the if:
System.out.println("JCanvas: isDoubleBuffered(): " + isDoubleBuffered());
if (!isDoubleBuffered()) {
Graphics2D g2d = (Graphics2D) g;
always yields "JCanvas: isDoubleBuffered(): false" under Windows XP on
a HP laptop with Sun's Java 1.5.0_11 and 1.6.0_05. So, the offscreen
code is not being used when I'm running. It might be different on a
multiscreen device though.
Do you get something similar? On what platform and JVM are you running?
Also, if I changed the conditional to
if (isDoubleBuffered()) {
then I got horrible black boxes in the damage area.
Do you see something similar?
BTW - One hack is to increase the memory by using the -Xmx option to
java. I'm fairly certain you know about this, but I thought I'd
mention it.
To increase the memory:
bash-3.2$ export JAVAFLAGS=-Xmx666m
bash-3.2$ $PTII/bin/vergil -v ../../ptolemy/domains/sdf/demo/Butterfly/Butterfly.xml
To verify how much memory, do View -> JVM Properties and look at
the Max memory line at the top.
Still, I'm curious as to whether the double buffering is necessary
and if it is right, so let me know if isDoubleBuffered() is returning
true for you and what happens if you reverse the isDoubleBuffered()
conditional.
_Christopher
--------
I have a small problem with Kepler / Ptolemy if I have too may windows
open, or if I accidentally hit the maximize window button in that my PC
hangs. This is seemingly due to memory issues in the Java VM. I have 3
monitors, so hitting the full-screen button creates a 3840 x 1024 window.
To see what was using so much memory, I had a poke around in Diva and
found some odd code in JCanvas.
JCanvas has the following code in the paint method:
if (!isDoubleBuffered()) {
Graphics2D g2d = (Graphics2D) g;
// Clear the clip region to the background color
g2d.setBackground(getBackground());
if (_workaroundClearRectBug) {
g2d.clearRect(0, 0, clip.width, clip.height);
} else {
g2d.clearRect(clip.x, clip.y, clip.width, clip.height);
}
// Draw directly onto the graphics pane
if (paintAll) {
_canvasPane.paint(g2d);
} else {
_canvasPane.paint(g2d, clip);
}
} else {
// Get a new offscreen buffer if necessary. Clear the
reference
// to the off-screen buffer, so that the memory can be freed
// if necessary by the GC and reallocated for the new buffer.
if ((_offscreen == null) || (_offscreen.getWidth() !=
clip.width)
|| (_offscreen.getHeight() != clip.height)) {
_offscreen = null; // in case GC needs it
_offscreen = new BufferedImage(clip.width, clip.height,
BufferedImage.TYPE_INT_RGB);
}
Graphics2D g2d = _offscreen.createGraphics();
// ------------ code removed for brevity --------------
// Blit it to the onscreen buffer
g.drawImage(_offscreen, clip.x, clip.y, null);
}
So, if the system is not keeping a backing buffer itself
(isDoubleBuffered() returns false) JCanvas draws directly to the screen.
If the system is keeping a backing buffer though then JCanvas creates
another backing buffer of it's own and uses that. It then blits that to
the system backing buffer ... which then in turn is blitted to the screen.
This makes no sense to me. If anything, the logic should be reversed which
would cause a backing buffer to be always used regardless of whether the
system has one or not. As it stands now though, it would appear that we
either use no backing buffer, or we use 2 of them. Given that in Java 5
and above top-level components are double buffered by default, Diva is
always creating an extra, unnecessary backing buffer.
It would appear that one could simply delete all of the _offscreen code
from JCanvas and it would remain functionally the same in terms of when a
backing store is used. Am I missing something?
Ian
************************************************************
HSBC Bank plc may be solicited in the course of its placement efforts for
a new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents a
potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to
the corporate finance client about the valuation and pricing of the
offering as well as internal systems, controls and procedures to identify
and manage conflicts of interest.
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority.
************************************************************
-----------------------------------------
SAVE PAPER - THINK BEFORE YOU PRINT!
This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and/or distributed to any other person. Each page
attached hereto must be read in conjunction with any disclaimer
which forms part of it. Unless otherwise stated, this transmission
is neither an offer nor the solicitation of an offer to sell or
purchase any investment. Its contents are based on information
obtained from sources believed to be reliable but HSBC makes no
representation and accepts no responsibility or liability as to its
completeness or accuracy.
--=_alternative 003ECB208025740A_=
Content-Type: text/html;
charset="US-ASCII"
<br><font size=2 face="sans-serif">I have a small problem with Kepler /
Ptolemy if I have too may windows open, or if I accidentally hit the maximi
ze
window button in that my PC hangs. This is seemingly due to memory issues
in the Java VM. I have 3 monitors, so hitting the full-screen button create
s
a 3840 x 1024 window. To see what was using so much memory, I had a poke
around in Diva and found some odd code in JCanvas.</font>
<br>
<br><font size=2 face="sans-serif">JCanvas has the following code in the
paint method:</font>
<br>
<br><font size=1 face="Courier New"> if (!isDoub
leBuffered())
{</font>
<br><font size=1 face="Courier New">
Graphics2D g2d = (Graphics2D) g;</font>
<br>
<br><font size=1 face="Courier New">
// Clear the clip region to the background color</font>
<br><font size=1 face="Courier New">
g2d.setBackground(getBackground());</font>
<br>
<br><font size=1 face="Courier New">
if (_workaroundClearRectBug) {</font>
<br><font size=1 face="Courier New">
g2d.clearRect(0, 0, clip.width, clip.height);</font>
<br><font size=1 face="Courier New">
} else {</font>
<br><font size=1 face="Courier New">
g2d.clearRect(clip.x, clip.y, clip.width, clip.height)
;</font>
<br><font size=1 face="Courier New">
}</font>
<br>
<br><font size=1 face="Courier New">
// Draw directly onto the graphics pane</font>
<br><font size=1 face="Courier New">
if (paintAll) {</font>
<br><font size=1 face="Courier New">
_canvasPane.paint(g2d);</font>
<br><font size=1 face="Courier New">
} else {</font>
<br><font size=1 face="Courier New">
_canvasPane.paint(g2d, clip);</font>
<br><font size=1 face="Courier New">
}</font>
<br><font size=1 face="Courier New"> } else
{</font>
<br><font size=1 face="Courier New">
// Get a new offscreen buffer if necessary. Clear the reference</fon
t>
<br><font size=1 face="Courier New">
// to the off-screen buffer, so that the memory can be freed</font>
<br><font size=1 face="Courier New">
// if necessary by the GC and reallocated for the new buffer.</font>
<br><font size=1 face="Courier New">
if ((_offscreen == null) || (_offscreen.getWidth() != clip.width)</f
ont>
<br><font size=1 face="Courier New">
|| (_offscreen.getHeight() != clip.heigh
t))
{</font>
<br><font size=1 face="Courier New">
_offscreen = null; // in case GC needs it</font>
<br><font size=1 face="Courier New">
_offscreen = new BufferedImage(clip.width, clip.height
,</font>
<br><font size=1 face="Courier New">
BufferedImage.TYPE_INT_RGB
);</font>
<br><font size=1 face="Courier New">
}</font>
<br>
<br><font size=1 face="Courier New">
Graphics2D g2d = _offscreen.createGraphics();</font>
<br>
<br><font size=1 face="Courier New"> //
------------ code removed for brevity --------------</font>
<br><font size=1 face="Courier New">
// Blit it to the onscreen buffer</font>
<br><font size=1 face="Courier New">
g.drawImage(_offscreen, clip.x, clip.y, null);</font>
<br><font size=1 face="Courier New"> }</font>
<br>
<br><font size=2 face="sans-serif">So, if the system is not keeping a backi
ng
buffer itself (isDoubleBuffered() returns false) JCanvas draws directly
to the screen. If the system is keeping a backing buffer though then JCanva
s
creates another backing buffer of it's own and uses that. It then blits
that to the system backing buffer ... which then in turn is blitted to
the screen.</font>
<br><font size=2 face="sans-serif">This makes no sense to me. If anything,
the logic should be reversed which would cause a backing buffer to be alway
s
used regardless of whether the system has one or not. As it stands now
though, it would appear that we either use no backing buffer, or we use
2 of them. Given that in Java 5 and above top-level components are double
buffered by default, Diva is always creating an extra, unnecessary backing
buffer.</font>
<br>
<br><font size=2 face="sans-serif">It would appear that one could simply
delete all of the _offscreen code from JCanvas and it would remain function
ally
the same in terms of when a backing store is used. Am I missing something?<
/font>
<br>
<br><font size=2 face="sans-serif">Ian</font>
<br><font size=2 face="sans-serif"><br>
<br>
************************************************************<br>
HSBC Bank plc may be solicited in the course of its placement efforts for
a new issue, by investment clients of the firm for whom the Bank as a firm
already provides other services. It may equally decide to allocate to its
own proprietary book or with an associate of HSBC Group. This represents
a potential conflict of interest. HSBC Bank plc has internal arrangements
designed to ensure that the firm would give unbiased and full advice to
the corporate finance client about the valuation and pricing of the offerin
g
as well as internal systems, controls and procedures to identify and manage
conflicts of interest.<br>
<br>
HSBC Bank plc<br>
Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom<br>
Registered in England - Number 14259<br>
Authorised and regulated by the Financial Services Authority.<br>
************************************************************<br>
</font>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
SAVE PAPER - THINK BEFORE YOU PRINT!
This transmission has been issued by a member of the HSBC Group "HSBC" for
the information of the addressee only and should not be reproduced and/or di
stributed to any other person. Each page attached hereto must be read in con
junction with any disclaimer which forms part of it. Unless otherwise stated
, this transmission is neither an offer nor the solicitation of an offer to
sell or purchase any investment. Its contents are based on information obtai
ned from sources believed to be reliable but HSBC makes no representation an
d accepts no responsibility or liability as to its completeness or accuracy.
</STRONG></P></BODY></HTML>
--=_alternative 003ECB208025740A_=--
--===============0171259067==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--===============0171259067==--
--------
More information about the Kepler-dev
mailing list