Hi Sunburned,
the file listed is part of the PIROL classes that Stefan integrated a
while ago. The source code should be there in the corresponding package
folder, so this should not be a problem with a missing jar, as the
source for these classes is included in the source code archives. Have
My work on OpenJUMP's pluggable renderers has prompted me to ask a
question about the basic operation or functionality rendering system.
The LayerViewPanel class defines two methods that both involve
rendering. The first is paintComponent() and the second is repaint().
After studying both methods
I'm having some trouble building the OpenJUMP 1.2 B release from
source code. I'm getting import error statements in most of the "de"
packages. For example, the following import statement raises a flag:
import de.fho.jump.pirol.utilities.debugOutput.DebugUserIds;
I've configured my build path in
I think I have figured out why my pluggable rendering system didn't
throw a NullPointerExcpetion when loading a new Layer, but why it does
when OpenJUMP starts with a new or empty project, or when the Layer
View is panned or zoomed.
I believe the LayerViewPanel.paintComponent() method calls the
Re
Ole has already identified and fixed my problem in OpenJUMP's
RenderingManger class.
The problem wasn't in the render(Object ContentID, boolean
clearImageCache) method, but in my implementation of the
createRenderer() method.
When I received a null value in the render(Object ContentID) method
cre
Thanks for the link Michael. Will you have time to make these changes
to OpenJUMP?
If you do not I will make time for it this week.
SS
On 5/21/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> Michaël,
>
>Looks like a good plan on the
> SkyJUMP+OpenJUMP+Synchronization wiki page. The priorities
Hi,
> Hi Michaël,
>You are one step ahead of me. I had just reached the same
> conclusion and did the mods to remove the references and it worked.
You are a step ahead of me because I still have to do the mods ;-)
Thanks for giving classes to modify
Do you know that I started to compile th
Nice work Michael. We will have to do some further investigation, but
it sounds like the rendering system is keeping references to the
Features in a Layer after the Layer is deleted.
I'm curiuos, how do you get a dump of the JVM heap like that?
The Sunburned Surveyor
Larry,
Thanks for clarifying that. I'm going to compare the render() methods
in JUMP, OpenJUMP, and in my modified code.
When I changed the statement
if (getRenderer(contentID).equals(null))
back to the statement
if (getRenderer(contentID == null)
the NullPointerException is generated in a la
Hi,
I think I get it ;
Here is what I obtained after a dump of jump's memory
I loaded a shapefile, I deleted it from the menu, then I made a dump of
the the heap
in order to get the objects dependency graph with the jhat analyser :
My 10 BasicFeatures are held in a list
which in turn is referen
Wishful thinking. There are no layers in an empty project, so there are no
renders.
Larry
On 5/21/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
I just realized OpenJUMP isn't passing the LayerViewPanel or any other
"phantom" object to the render() method.
The only way the
if (getRendere
I just realized OpenJUMP isn't passing the LayerViewPanel or any other
"phantom" object to the render() method.
The only way the
if (getRenderer(contentID).equals(null))
statement could be causing a NullPointerException is if OpenJUMP was
passing the render() method a null value.
I think it doe
Larry,
This makes sense. I didn't think about the fact that I was calling the
Object.equals method in this line.
I find your comments interesting because a Layer object is not passed
to OpenJUMP when a project is first opened. Maybe this is why I can
rendering works with no error when I load a Sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SS,
Unit test is fine, but take a suggestion wrong an old coder:
println debugging has its merits and setting a break point
in your debugger to introspect some variables may save your day. ;-)
- - Sascha
Sunburned Surveyor schrieb:
> Sascha,
>
> Th
Hi SS,
You said:
The line that is generating the error mesage is this:
if (getRenderer(contentID).equals(null))
The only way that could be true is if contentID is null. If I remember
correctly, contentID is basically the layer object.
Larry
On 5/21/07, Sunburned Surveyor <[EMAIL PROTECTED]
This may be a really stupid thing to suggest, but I'll throw it out there
anyways.
In JUMP there is a LayerListener interface defined. Is it possible that a
plug-in would implement this interface in a way that would hold onto a
reference to a Layer object?
For instance, I see that both the Layer
Sascha,
This is how the method was coded first, and I still got the error
message. I changed it today thinking that might fix the problem.
Do you have any other ideas?
The Sunburned Surveyor
On 5/21/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
What about rewriting
getRenderer(contentID).equals(null)
as
getRenderer(contentID) == null
?
- - Sascha
Sunburned Surveyor schrieb:
> I'm about ready to give up on this pluggable rendering system for
> OpenJUMP. :]
>
> I created JUnit tests
I'm about ready to give up on this pluggable rendering system for OpenJUMP. :]
I created JUnit tests for the two main classes involved, namely
RendererFactory and RegularRendererFactoryTool. All the JUnit tests
for the public methods in both the classes pass with no problems now
that I have made
It seems likely that there are stale references somewhere, then. I remember
an older version of the GridBagLayout used to have a bug where all obljects
added to it were hung onto for the life of the GBL, because the remove code
didn't take refernces out of an internal Hashtable. Has anybody tried
I think is a problem with the code, like Larry says , i think is possible to free memory but the gc() doesn´t work because there are references to the Layer.
DAVID GARCIA
From: "Larry Becker" <[EMAIL PROTECTED]>Reply-To: "List for discussion of JPP development and use." To: "List for discussio
Hi Craig,
Good point, however if you close the task (project) all memory is
reclaimed, so it would seem to be possible to reclaim it by removing a
layer.
Larry
On 5/21/07, A. Craig West <[EMAIL PROTECTED]> wrote:
Do we know if this is a problem with references being hung onto
internally, or
Do we know if this is a problem with references being hung onto
internally, or just the standard Java VM behavior where the Java VM
normally doesn't return memory to the OS?
-Craig
On 5/21/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> hei David,
>
> in case you don't know
> what sometimes can
hei David,
in case you don't know
what sometimes can help a bit is to press the "garbage collect" button
of the help/about/info tab
but only sometimes :I
stefan
david alejandro garcia ortega schrieb:
> Thanks Larry i will try to find a solution to the problem.
>
> DAVID GARCIA
>
>
Thanks Larry i will try to find a solution to the problem.
DAVID GARCIA
From: "Larry Becker" <[EMAIL PROTECTED]>Reply-To: "List for discussion of JPP development and use." To: "List for discussion of JPP development and use." Subject: Re: [JPP-Devel] Question?Date: Mon, 21 May 2007 11:03:03 -
Hi David,
Welcome to the list. That is an excellent question. I wish I had an
answer for you, but it is one of the unsolved problems with JUMP (all
flavors I believe). In my tests, it is not even consistent. Sometimes
removing a layer will free most of the memory, but usually it will not.
T
Hi I am working with the source code of OpenJump and i have the following question:
When I load a dataset(shapefile) commited memory is about 150Mb, then when I remove the dataset the commited memory is about 140Mb. Why doesn´t memory free?
I want to free memory when the layer is turned invisible
27 matches
Mail list logo
