[kepler-dev] question about Diva's JCanvas

ian.brown@hsbcib.com ian.brown at hsbcib.com
Wed Mar 12 04:25:52 PDT 2008


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080312/2cee05fe/attachment.htm


More information about the Kepler-dev mailing list