Greetings Everyone,
I am just wondering about something I stumbled over during programming. I
implemented a slice plane rendering for a voxel cube, meaning I needed to
create 2d images on the fly. My first approach was to use a BufferedImage
(only one) which I filled pixel by pixel with setRGB
Can you post sample code? Small runnable test will be best.
It is interesting to understand whether you call setRGB() for individual pixels
or arrays.
What type of buffered image are you using, etc.
[Message sent by forum member 'neigor' (neigor)]
consider this library Kollider2D (also available on google code).
New update very soon (today or tomorrow).
[Message sent by forum member 'orelero' (orelero)]
http://forums.java.net/jive/thread.jspa?messageID=269253
===
To
Sure. It is part of a bigger program, but I will try to extract what is needed
and turn it into a runnable example. I used setRGB for each pixel (not arrrays)
and for a TYPE_INT_ARGB image. Example will follow later.
[Message sent by forum member 'chaose71' (chaose71)]
As requested, here a small runnable test. When you run it please start the JVM
with something like -XX:NewSize=256m -XX:MaxNewSize=256m, elsehow the memory
message wont be of much use.
Here comes the code:
I am not sure what is going on. Perhaps this Runtime reporting wrong values.
I see that number printed to the console is growing but at the same time
i do not observe heap growth in the jconsole.
-igor
[EMAIL PROTECTED] wrote:
As requested, here a small runnable test. When you run it
Hello Igor,
thank you for your reply. Its not only the runtime the reporting: in the
original application where I extracted this code from, it produced a noticable
slowdown in the rendering threads because of the garbage collector runs.
As I said, since I am using MemoryImageSources now, it
The memory-leaking behavior is not relevant for me
anymore since I changed the implementation to
MemoryImageSource already, but I am still curious if
anyone has an idea why setting pixels consumes that
much memory.
I would really recommend not using MemoryImageSource. Its an API from the
Hmm, the forum is cropping my code. Is it to long? Do I need to use some tag
like [pre]? I will try to edit the post
[Message sent by forum member 'chaose71' (chaose71)]
http://forums.java.net/jive/thread.jspa?messageID=269280
I hope MemoryImageSource is not going to be depricated!!!
I use it big time in all my applets.
What would be the replacement for MemoryImageSource? I hope
you aren't thinking that BufferedImage is better. BufferedImage
is a giant, poorly thought out hairball...
[EMAIL PROTECTED] wrote:
The
Ken Warner wrote:
I hope MemoryImageSource is not going to be depricated!!!
I use it big time in all my applets.
What would be the replacement for MemoryImageSource? I hope
you aren't thinking that BufferedImage is better. BufferedImage
is a giant, poorly thought out hairball...
Here we
True - but thats an array. Depending on the internal representation of
DataBuffer (which I have not looked into yet), this could mean that the casting
has to be done for each element of the array.
The fact that using setRGB() for individual pixels costs so much memory, could
suggest that the
Is it
really faster then the MemoryImageSource approach?
Yes.
Can you try to modify my example code using your
suggestion, so that we can see if it produces
similiar memory leaking behavior or if it solves it?
Sorry, no ... I don't have the time.
I post a snippit which should be easy to
I only see a bunch of small collections (I tried on
6u10) - probably because for each pixel you set an
int[1] array is created.
I don't see the heap growing. Run it with -verbose:gc ,
see what it says.
If you want to try the approach Clemens suggested, you'll
only need to change
Hi Clemens,
okay - I tested it. Memory consumption is gone. Will do some performance
measuring later.
MfG;
ChaosE
[Message sent by forum member 'chaose71' (chaose71)]
http://forums.java.net/jive/thread.jspa?messageID=269324
One Raster? When I went through the same problem,
I had to do that three times to get the R,G,B channels.
[EMAIL PROTECTED] wrote:
[code]byte[]
data=((DataBufferByte)tex.getRaster().getDataBuffer())
.getData() [/code]
looks like there is a lot of casting involved.
I can see only one.
[EMAIL PROTECTED] wrote:
True - but thats an array. Depending on the internal representation of
DataBuffer (which I have not looked into yet), this could mean that the casting
has to be done for each element of the array.
Once you grab the Java array, you are done grabbing it and done
Just a small correction...
[EMAIL PROTECTED] wrote:
Can you try to modify my example code using your
suggestion, so that we can see if it produces
similiar memory leaking behavior or if it solves it?
Sorry, no ... I don't have the time.
I post a snippit which should be easy to use:
[code]
Hello Jim,
thanks a lot for the very comprehensive reply! It did perfectly answers all my
questions and even a few more ;) Glad to understand the strange memory
consumption a bit better now. It feels always better to understand the true
nature of an unknown phenomen!
Thanks again!
Ingo
PS: I
The first line is LCD text, the second line is greyscale.
The problem is that we do not have loops - in either software
or hardware, that work for LCD text with the composite you have specified.
There's an open bug on this: 6274808.
-phil.
[EMAIL PROTECTED] wrote:
Reposting from Swing AWT
Phil Race wrote:
The first line is LCD text, the second line is greyscale.
The problem is that we do not have loops - in either software
or hardware, that work for LCD text with the composite you have specified.
There's an open bug on this: 6274808.
Note that this bug mentions that complex
Phil,
Would that be fixed in the final 6u10?
Thanks
Kirill
[Message sent by forum member 'kirillcool' (kirillcool)]
http://forums.java.net/jive/thread.jspa?messageID=269392
===
To unsubscribe, send email to [EMAIL
Would you suggest emulating translucent text by interpolating the full color
with the background color (using full opacity)?
[Message sent by forum member 'kirillcool' (kirillcool)]
http://forums.java.net/jive/thread.jspa?messageID=269400
23 matches
Mail list logo
