Luca Vanon

Greenhorn
+ Follow
since Apr 03, 2018
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Luca Vanon

Guys, I think I found the solution.
If someone is searching for the same thing that's what I wrote in the code before closing the window:

I don't know if it's the perfect solution but it seems to work.
Thanks to all of you for your help!
4 years ago
If you want I can post some code, but just the way I create the SVGPanel because I have no idea on how to remove/dispose the panel.
I'm searching for info but everything I found tells you how to create it, not how to remove it.



It works perfectly and display the SVG file just fine, but I don't know how to free the allocated memory that keeps on growing as before with the "simple" images.
I'm searching for some methods or sub-classes of SVGPanel(), but with no luck for now.
4 years ago
Thanks guys, Al Hobbs found a good solution with the flush().
This seems to work with "simple" images, I did a few iterations and it seems that the memory exception is thrown only when the memory is actually not enough (that happens when you open more windows at the same time), but as soon as you close the windows when you re-open a window the image is loaded, this was not happening before and means that the resources are actually free again.

Thanks a lot, but now I have a new problem...
I don't know if I have to open a new discussion or we could go on here (I kindly ask the moderators if I have to move the discussion)...

The problem now is with the SVG images.
To render the SVG images I use an SVGPanel from the Salamander SVG library.
A very big memory leak is here because I don't know how to dispose the SVGPanel (it doesn't come with a .dispose method).
I'm searching for a solution in the Salamander repository but if you are familiar with this library and can help me it would be great.

Dave Tolls, I know that looking at the task manager is not the same that using a console to monitor the memory usage, but it helped me to understand why the exported jar project was crashing on a PC with less memory than my workstation.

Thanks again to all for your help!
4 years ago
As before, the dimension of the images is not the point.
You don't need a camera to generate a picture, you can do it with photoshop, 600dpi, big as a 2 meters poster or, it can be a different source as a SVG file with thousands of lines and curves rendered as an image, that's not the point.
I can tell you that with bigger images the effect is more evident and at the end throws an error, but the basic is the same: the memory is never released and always increase.
I still believe something is missing that prevent the garbage collector to set the window collectable.
That's the answer I'm searching for...
4 years ago
Hi guys, thanks to all for the answers, I really appreciate that.

Rob Camick, I will give a try to your code tomorrow when I'll go back to my office, thanks very much.

Campbell Ritchie, you said you tried that code with your photo and used about 66Mb.
I didn't check with jconsole but windows task manager is enough for me to see the increasing usage of memory.
So, 66Mb is not much, nut you didn't tell us if that memory is deallocated after the window is closed and that's the issue.
Let's say I open and close a window with a 66Mb picture 20 times, not the same picture and not the same window.
20 different windows with 20 different images.
If the memory is not deallocated each time sooner or later you will get an out of memory error.
For me the thing is faster because I use bigger images that increase like 200/300Mb every time they are loaded, and I have not only 3 windows but plenty of them.
That's said, this is not the point.
The fact that you didn't have errors with a few images of 66Mb is not telling me if the memory is still increasing or not (in mine the answer is yes, I never had a memory decrease, only increase).

As I said, the point is: why the memory is not deallocated after disposing the window?

Carey Brown, I'm sorry if I didn't give you more information, but my original question was more "theorical"...
What is the correct way to dispose a window (JFrame, JDialog or even a single JLabel) in order to avoid memory leak?
Speaking of practical stuff, the piece of code with 3 buttons throw an exception, just try with much bigger images, something big enough to raise the memory allocation to 400/500Mb.
You don't need to replicate the error, just take a look at the task manager and you will see that the memory allocation keep on growing and never decrease after the windows are closed.
No corrupted images, just take very big ones, but, again, that's not the point. With smaller images the thing will happen again with more iterations.
In my opinion I'm doing something wrong that didn't deallocate the memory when I close the windows.
Please, answer me a question: is the memory decreasing when you close the windows? If not something is wrong...

4 years ago
I don't want to be misunderstood: I really appreciate your help, but again, that's not the point.
I don't want to use less memory, make the heap size bigger or other solutions that will only procastinate the problem.
My program must be able to open and close multiple session, unlimited times, so even if the images allocate less memory sooner or later the free memory will finish.
My question is still ununswered: what is the correct way to allocare and that deallocate the memory for that image?
Why dispose doesn't work?
Let's say I'm doing a program that opens an image, let you write something on it and then save.
Then open a new one, close it, and again, multiple times, more than one at a time...
Why closing the windows doesn't deallocate the memory used to render the image?
4 years ago
Thanks, but that's not an answer to my question.
As I said this is just an example.
The real application has a lot of images, big images, but that's not the point.
The point is: how can I free the memory allocated?
Why disposing the element doesn't free the memory?
I don't want to avoid creating new images, new labels, new dialogs, new frames, I need them couse my program has to be able to handle multiple sessions of the same frames/dialogs etc. simultaniously.
But, again, that's not the point.
I want to understand why disposing an element is not deallocating the memory and how can I do that hundreds of times, if necessary.
Thanks.
4 years ago
This is not the original code, just an example I made to get to the point:



This simply create a JFrame with 3 JButton opening 3 different JDialog each one has a label with a big image inside.

They are set to DISPOSE_ON_CLOSE so what I expect is:

1) I press the first button: the JDialog opens and a big amount of memory is allocated.
2) I close the JDialog with the X and it is disposed (so set to be collectable from the garbage collector or something like that when needed)
3) I press the second button: the second JDialog should open (because the first one is no longer in use and it's resources should be collected and free)

Unfortunately that's not the case...
After pressing the second button I receive a "java.lang.OutOfMemoryError: Java heap space"

What should I do to free the memory allocated in the first JDialog?
Why after his disposal it is not collected?
Thanks for your help!
4 years ago
Thanks for the reply.
As I said the program I wrote is very long and complex, but that's not the point.
I don't want to know what I'm doing wrong (I will discover it myself later), I want to know what is the correct way to do it.
I tried so much things that I have a lot of difficulties to write a list.
Could you write a small program that simply open a JLabel inside a JFrame or a JDialog with an image and then dispose it so that no memory leaks occours?
I understood after many attempts that simply disposing the JDialog or JFrame cause infinite memory leaks.
Thanks for the support!
4 years ago
Hi guys, please, I need help.
I'm facing a big memory leak problem handling images in a swing application.
The program I wrote is very complex and thousands of lines long, I will not post code here because it's not the point of what I'm asking.
What I am asking is: what is the best way to load/unload an image, for example in a simple JLabel, to avoid memory leak?
I read a lot of forums and tried a lot of solution but unfortunately none worked.
Could you be so kind to give me a hint of code that can load an image on a JLabel and then unload it and then free the memory allocated (forcing the garbage collector or making sure that is collectable)?
All the solutions I tried so far are not resolving the memory leak.
As I said, please don't ask me lines of code, just give me the right solution so I can implement it later.
The code I need should open a JLabel (on a JFrame or JDialog, it doesn't matter) with an image inside and then close it (dispose or whatever) in order to free the memory allocated so that calling it again and again and again won't cause any memory issue.
Thanks in advance for your help.
4 years ago
Looking better (examining pixels) it seems that something change actually loading tahoma.ttf or tahomabd.ttf and also setting Font.PLAIN or Font.BOLD, so I guess I'm doing things correctly.
But every combination I try it never looks like setting the system font.
In other words:

Doesn't look like:

The second really looks BOLD, the first is like thicker than PLAIN, but not really BOLD...
5 years ago
Another update.
The problem in tahoma bold only happens when I load the stream from the ttf file (no matter if it's tahoma.ttf or tahomabd.ttf, the result is always not bold).
Using system fonts like this:

Works perfectly, but obviously this will not work if the font is not installed in the system.
5 years ago
Just an update...
Using arial instead of tahoma with the only file arial.ttf (no arialbd.ttf loaded) seems to work setting Font.BOLD.
I prefer to use tahoma if I can get it to work....
5 years ago
Hello, I'm back from the weekend...
Here is the code for the plain tahoma font, size 16, file tahoma.ttf:

Setting Font.BOLD makes no changes (even if on the labels with HTML content the bold tag makes the text bold).

Here's the code for the bold font, file tahomabd.ttf, size 16:

This appear like the first one, even if the file loaded should be the bold one.
Changing Font.PLAIN or Font.BOLD makes no difference.
The code runs with no errors on the console.
5 years ago
I think it's probably the philosophy of a forum...
More people answering at the same time the same question, that's what you normally do on a forum, right?
If I have an answer I'm not gonna say: Oh, there is already someone working on that, they certainly don't need my solution...
But that's my opinion...
By the way, anyone considering a solution for my problem?
Thanks
5 years ago