[kepler-dev] question about Diva's JCanvas
ian.brown@hsbcib.com
ian.brown at hsbcib.com
Thu Mar 13 02:20:45 PDT 2008
Christoper,
I can confirm what you're seeing. I never did the check of
changing the code - I was just code reading it and it looked wrong. It now
looks like it's more broken than it first looked :) I guess there
shouldn't be any harm in chopping out the double buffering code from
JCanvas then given that it is not used and does not work.
As for the memory issues, I already run with 1Gig allocated for the JVM.
The main issue is that I have lots of composite actors and each one opens
in its own window which in Java 6 apparently has its own back-buffer. I
guess a 'solution' may be to allow a composite actor to open in the same
window as the parent when navigating into it (a bit like following a link
in a browser - normally the new page will open in the same browser window
unless you explicitly ask for a new window). To complete this paradigm,
the toolbar would need a 'up' button which would display the containing
composite or model if one exists.
Ian
"Christopher Brooks" <cxh at eecs.berkeley.edu>
Sent by: cxh at EECS.Berkeley.EDU
13/03/2008 03:20
Mail Size: 18857
To
Ian BROWN/IBEU/HSBC at HSBC
cc
kepler-dev at ecoinformatics.org
Subject
Re: [kepler-dev] question about Diva's JCanvas
Entity
Investment Banking Europe - IBEU
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==--
--------
************************************************************
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080313/7f95b52e/attachment-0001.htm
More information about the Kepler-dev
mailing list