[kepler-dev] question about Diva's JCanvas
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Mar 13 08:41:34 PDT 2008
Hi Ian,
I agree that the code is rather broken. I'll look it over.
I'm curious as to when isDoubleBuffered() would return true though.
It probably does at some point. I'm surprised that it is not
returning true under Java 1.6.
About the memory size, we have a model that is has these statistics:
2.62Mb file size
The model consists of 40.2k lines of MoML
The breakdown of the model is:
AtomicEntities: 12920
CompositeEntities: 1642
Relations: 22415
Attributes: 65331
I think it runs in about 600Mb of memory. So, it is possible to
have fairly large models. The model is SDF though, so the
problems could with the domain.
I regularly open up all the models within Ptolemy, which is about 200
windows. Note that Kepler runs out of memory well before opening up
the 200 models because Kepler uses SVG and there is an issue with Kepler
using the -Xms command line argument, which uses memory.
One of the features we've considered adding is an "up" button that
would display the container composite actor. This would not
solve your problem though, since we would have multiple windows.
Another possibilities is to try to use the Thales single window
interface, see ptII/thales. However, I have not tried it in a while,
and I think it basically renders the window and then reparents it,
thus it would have similar issues.
We are also looking at various possibilities of using Eclipse or
NetBeans to create a single window interface. Yesterday, I was able
to hack up embedding the Vergil graph viewer pane into Eclipse's SWT.
Progress in this area is a long way off though, what I did was a
brutal proof of concept hack.
One thing that might help in the near term is looking at memory usage
with JProbe or JProfiler. Often there are obvious solutions for
low hanging fruit.
_Christopher
--------
This is a multipart message in MIME format.
--=_alternative 003357338025740B_=
Content-Type: text/plain;
charset="US-ASCII"
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.
--=_alternative 003357338025740B_=
Content-Type: text/html;
charset="US-ASCII"
<br><font size=2 face="sans-serif">Christoper,</font>
<br><font size=2 face="sans-serif"> 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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Ian</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Christopher Brooks&qu
ot;
<cxh at eecs.berkeley.edu></b> </font>
<br><font size=1 face="sans-serif">Sent by: cxh at EECS.Berkeley.EDU</font>
<p><font size=1 face="sans-serif">13/03/2008 03:20</font>
<br><font size=1 color=#808080 face="sans-serif"><b>Mail Size: 18857</b></f
ont>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">Ian BROWN/IBEU/HSBC at HSBC</fon
t>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">kepler-dev at ecoinformatics.org
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: [kepler-dev] question
about Diva's JCanvas</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Entity</font></div>
<td valign=top><font size=1 face="sans-serif">Investment Banking Europe
- IBEU</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Ian,<br>
Interesting!<br>
<br>
I started looking into this. The double buffering code has<br>
been in diva.canvas.JCanvas since June, 1998.<br>
<br>
http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.
4.4
<br>
says:<br>
<br>
2.4.4 Swing's true double buffering<br>
<br>
Swing's true double buffering has now been enabled. Swing used to<br
>
provide double buffering on an application basis, it now provides
it<br>
on a per-window basis and native exposed events are copied directly<
br>
from the double buffer. This significantly improves Swing performanc
e,<br>
especially on remote servers.<br>
<br>
Please see the Scott Violet's Blog for full details. <br>
http://weblogs.java.net/blog/zixle/archive/2005/04/no_more_gray_re_1
.html<br>
<br>
There is a bug that says this is fixed in Java 1.6:<br>
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4967886<br>
<br>
I looked around and I can't be sure exactly when the Java release<br>
changed. The Java release notes for 1.5 and 1.6 are not much help.<br
>
I'm just curious, do you have a reference for when the double<br>
buffering changed?<br>
<br>
We are still supporing Java 1.5, so we might need to conditionalize<br>
this. <br>
<br>
Putting a println statement before the if:<br>
<br>
System.out.println("JCanvas: isDoubleBuffe
red():
" + isDoubleBuffered());<br>
if (!isDoubleBuffered()) {<br>
Graphics2D g2d = (Graphics2D)
g;<br>
<br>
always yields "JCanvas: isDoubleBuffered(): false" under Windows
XP on<br>
a HP laptop with Sun's Java 1.5.0_11 and 1.6.0_05. So, the offscreen<
br>
code is not being used when I'm running. It might be different on
a<br>
multiscreen device though.<br>
<br>
Do you get something similar? On what platform and JVM are you runnin
g?<br>
<br>
Also, if I changed the conditional to<br>
if (isDoubleBuffered()) {<br>
then I got horrible black boxes in the damage area.<br>
<br>
Do you see something similar?<br>
<br>
BTW - One hack is to increase the memory by using the -Xmx option to<br>
java. I'm fairly certain you know about this, but I thought I'd<br>
mention it.<br>
To increase the memory:<br>
bash-3.2$ export JAVAFLAGS=-Xmx666m<br>
bash-3.2$ $PTII/bin/vergil -v ../../ptolemy/domains/sdf/demo/Butterfly/Butt
erfly.xml<br>
<br>
<br>
To verify how much memory, do View -> JVM Properties and look at<br>
the Max memory line at the top.<br>
<br>
Still, I'm curious as to whether the double buffering is necessary<br>
and if it is right, so let me know if isDoubleBuffered() is returning<br>
true for you and what happens if you reverse the isDoubleBuffered()<br>
conditional.<br>
<br>
_Christopher<br>
<br>
--------<br>
<br>
I have a small problem with Kepler / Ptolemy if I have too
may windows <br>
open, or if I accidentally hit the maximize window button
in that my PC <br>
hangs. This is seemingly due to memory issues in the Java
VM. I have 3 <br>
monitors, so hitting the full-screen button creates a 3840
x 1024 window. <br>
To see what was using so much memory, I had a poke around
in Diva and <br>
found some odd code in JCanvas.<br>
<br>
JCanvas has the following code in the paint method:<br>
<br>
if (!isDoubleBuffered()) {<br>
Graphics2D g2d
= (Graphics2D) g;<br>
<br>
// Clear the clip
region to the background color<br>
g2d.setBackground(g
etBackground());<br>
<br>
if (_workaroundClea
rRectBug)
{<br>
g2d.c
learRect(0,
0, clip.width, clip.height);<br>
} else {<br>
g2d.c
learRect(clip.x,
clip.y, clip.width, clip.height);<br>
}<br>
<br>
// Draw directly
onto the graphics pane<br>
if (paintAll) {<br>
_canv
asPane.paint(g2d);<br>
} else {<br>
_canv
asPane.paint(g2d,
clip);<br>
}<br>
} else {<br>
// Get a new offscr
een
buffer if necessary. Clear the <br>
reference<br>
// to the off-scree
n
buffer, so that the memory can be freed<br>
// if necessary
by the GC and reallocated for the new buffer.<br>
if ((_offscreen
== null) || (_offscreen.getWidth() != <br>
clip.width)<br>
|| (_offscreen.getHeight() != clip.height)) {<br>
_offs
creen
= null; // in case GC needs it<br>
_offs
creen
= new BufferedImage(clip.width, clip.height,<br>
BufferedImage.TYPE_INT_RGB);<br>
}<br>
<br>
Graphics2D g2d
= _offscreen.createGraphics();<br>
<br>
// ------------ code removed
for brevity --------------<br>
// Blit it to the
onscreen buffer<br>
g.drawImage(_offscr
een,
clip.x, clip.y, null);<br>
}<br>
<br>
So, if the system is not keeping a backing buffer itself
<br>
(isDoubleBuffered() returns false) JCanvas draws directly
to the screen. <br>
If the system is keeping a backing buffer though then JCanvas
creates <br>
another backing buffer of it's own and uses that. It then
blits that to <br>
the system backing buffer ... which then in turn is blitted
to the screen.<br>
This makes no sense to me. If anything, the logic should
be reversed which <br>
would cause a backing buffer to be always used regardless
of whether the <br>
system has one or not. As it stands now though, it would
appear that we <br>
either use no backing buffer, or we use 2 of them. Given
that in Java 5 <br>
and above top-level components are double buffered by default
,
Diva is <br>
always creating an extra, unnecessary backing buffer.<br>
<br>
It would appear that one could simply delete all of the _offs
creen
code <br>
from JCanvas and it would remain functionally the same in
terms of when a <br>
backing store is used. Am I missing something?<br>
<br>
Ian<br>
<br>
<br>
************************************************************<
br>
HSBC Bank plc may be solicited in the course of its placement
efforts for <br>
a new issue, by investment clients of the firm for whom the
Bank as a firm <br>
already provides other services. It may equally decide to
allocate to its <br>
own proprietary book or with an associate of HSBC Group.
This represents a <br>
potential conflict of interest. HSBC Bank plc has internal
arrangements <br>
designed to ensure that the firm would give unbiased and
full advice to <br>
the corporate finance client about the valuation and pricing
of the <br>
offering as well as internal systems, controls and procedures
to identify <br>
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>
<br>
<br>
<br>
-----------------------------------------<br>
SAVE PAPER - THINK BEFORE YOU PRINT!<br>
<br>
This transmission has been issued by a member of the HSBC
Group<br>
"HSBC" for the information of the addressee only
and should not be<br>
reproduced and/or distributed to any other person. Each page<
br>
attached hereto must be read in conjunction with any disclaim
er<br>
which forms part of it. Unless otherwise stated, this transmi
ssion<br>
is neither an offer nor the solicitation of an offer to sell
or<br>
purchase any investment. Its contents are based on informatio
n<br>
obtained from sources believed to be reliable but HSBC makes
no<br>
representation and accepts no responsibility or liability
as to its<br>
completeness or accuracy.<br>
--=_alternative 003ECB208025740A_=<br>
Content-Type: text/html;<br>
charset="US-ASCII"<br>
<br>
<br>
<br><font size=2 face="sans-serif">I
have a small problem with Kepler /<br>
Ptolemy if I have too may windows open, or if I accidentally
hit the maximi<br>
ze<br>
window button in that my PC hangs. This is seemingly due
to memory issues<br>
in the Java VM. I have 3 monitors, so hitting the full-screen
button create<br>
s<br>
a 3840 x 1024 window. To see what was using so much memory,
I had a poke<br>
around in Diva and found some odd code in JCanvas.</font&g
t;<br>
<br><br>
<br><font size=2 face="sans-serif">JCan
vas
has the following code in the<br>
paint method:</font><br>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; if (!isDoub<br>
leBuffered())<br>
{</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; Graphics2D g2d = (Graphics2D) g;</font><br>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // Clear the clip region to the background color&l
t;/font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; g2d.setBackground(getBackground());</font><b
r>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; if (_workaroundClearRectBug) {</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; g2d.clearRect(0, 0, clip.wid
th,
clip.height);</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; } else {</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; g2d.clearRect(clip.x, clip.y
,
clip.width, clip.height)<br>
;</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; }</font><br>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // Draw directly onto the graphics pane</font&g
t;<br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; if (paintAll) {</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; _canvasPane.paint(g2d);</
font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; } else {</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; _canvasPane.paint(g2d, clip)
;</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; }</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; } else<br>
{</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // Get a new offscreen buffer if necessary. Clear
the reference</fon<br>
t><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // to the off-screen buffer, so that the memory
can be freed</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // if necessary by the GC and reallocated for
the new buffer.</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; if ((_offscreen == null) || (_offscreen.getWidth()
!= clip.width)</f<br>
ont><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ||
(_offscreen.getHeight() != clip.heigh<br>
t))<br>
{</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; _offscreen = null; // in
case GC needs it</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; _offscreen = new BufferedIma
ge(clip.width,
clip.height<br>
,</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n
bsp;
&nbsp; BufferedImage.TYPE_INT_RGB<br>
);</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; }</font><br>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; Graphics2D g2d = _offscreen.createGraphics();</
font><br>
<br><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; //<br>
------------ code removed for brevity --------------</font
><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; // Blit it to the onscreen buffer</font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; &nbsp;<br>
&nbsp; g.drawImage(_offscreen, clip.x, clip.y, null);<
/font><br>
<br><font size=1 face="Courier New">&am
p;nbsp;
&nbsp; &nbsp; &nbsp; }</font><br>
<br><br>
<br><font size=2 face="sans-serif">So,
if the system is not keeping a backi<br>
ng<br>
buffer itself (isDoubleBuffered() returns false) JCanvas
draws directly<br>
to the screen. If the system is keeping a backing buffer
though then JCanva<br>
s<br>
creates another backing buffer of it's own and uses that.
It then blits<br>
that to the system backing buffer ... which then in turn
is blitted to<br>
the screen.</font><br>
<br><font size=2 face="sans-serif">This
makes no sense to me. If anything,<br>
the logic should be reversed which would cause a backing
buffer to be alway<br>
s<br>
used regardless of whether the system has one or not. As
it stands now<br>
though, it would appear that we either use no backing buffer,
or we use<br>
2 of them. Given that in Java 5 and above top-level component
s
are double<br>
buffered by default, Diva is always creating an extra, unnece
ssary
backing<br>
buffer.</font><br>
<br><br>
<br><font size=2 face="sans-serif">It
would appear that one could simply<br>
delete all of the _offscreen code from JCanvas and it would
remain function<br>
ally<br>
the same in terms of when a backing store is used. Am I missi
ng
something?<<br>
/font><br>
<br><br>
<br><font size=2 face="sans-serif">Ian&
lt;/font><br>
<br><font size=2 face="sans-serif"><
br><br>
<br><br>
************************************************************&
lt;br><br>
HSBC Bank plc may be solicited in the course of its placement
efforts for<br>
a new issue, by investment clients of the firm for whom the
Bank as a firm<br>
already provides other services. It may equally decide to
allocate to its<br>
own proprietary book or with an associate of HSBC Group.
This represents<br>
a potential conflict of interest. HSBC Bank plc has internal
arrangements<br>
designed to ensure that the firm would give unbiased and
full advice to<br>
the corporate finance client about the valuation and pricing
of the offerin<br>
g<br>
as well as internal systems, controls and procedures to ident
ify
and manage<br>
conflicts of interest.<br><br>
<br><br>
HSBC Bank plc<br><br>
Registered Office: 8 Canada Square, London E14 5HQ, United
Kingdom<br><br>
Registered in England - Number 14259<br><br>
Authorised and regulated by the Financial Services Authority.
<br><br>
************************************************************&
lt;br><br>
</font><br>
<HTML><BODY><P><hr size=1></P><
br>
<P><STRONG><br>
SAVE PAPER - THINK BEFORE YOU PRINT!<br>
<br>
This transmission has been issued by a member of the HSBC
Group "HSBC" for <br>
the information of the addressee only and should not be reproduced
and/or di<br>
stributed to any other person. Each page attached hereto must be
read in con<br>
junction with any disclaimer which forms part of it. Unless otherwi
se
stated<br>
, this transmission is neither an offer nor the solicitation of
an offer to <br>
sell or purchase any investment. Its contents are based on informat
ion
obtai<br>
ned from sources believed to be reliable but HSBC makes no represen
tation
an<br>
d accepts no responsibility or liability as to its completeness
or accuracy.<br>
</STRONG></P></BODY></HTML><br>
--=_alternative 003ECB208025740A_=--<br>
<br>
<br>
--===============0171259067==<br>
Content-Type: text/plain; charset="us-ascii"<br>
MIME-Version: 1.0<br>
Content-Transfer-Encoding: 7bit<br>
Content-Disposition: inline<br>
<br>
_______________________________________________<br>
Kepler-dev mailing list<br>
Kepler-dev at ecoinformatics.org<br>
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo
/kepler-dev<br>
<br>
--===============0171259067==--<br>
--------<br>
</tt></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 003357338025740B_=--
--------
More information about the Kepler-dev
mailing list