Posted by
Michael Bien on
Jan 24, 2011; 11:08pm
URL: https://forum.jogamp.org/method-not-implemented-gluScaleImage-tp2304656p2324343.html
the problem here is prob. that the jvm is unable to allocate small
dbbs (direct byte buffers). It will usually give you a to around 4mb
rounded chunk and just claim that its smaller (at least it was the case
around 2 years ago as i checked the code). I have the same problem in
jocl and try to be very careful with buffer allocation internally
(static allocated sliced buffers, and in worst case threadlocal static
buffers). dbbs are allocated in the perm generation which is usually
only swept in full garbage collections.
when debugging this issues i recommend to use a recent JDK (6 or 7)
since it has usually better diagnostic messages in the OOM exceptions.
(jvisualvm is also quite cool for monitoring the permgen)
-michael
On 01/24/2011 11:47 PM, Wade Walker [via jogamp] wrote:
>
> Found it. Class Type_Widget that's used in Image allocates its buffer as
> "direct" in JOGL2, but it didn't in JOGL1.
>
> public Type_Widget() {
> buffer = ByteBuffer.allocate( 4 ); // JOGL 1
> }
>
> public Type_Widget() {
> buffer = ByteBuffer.allocateDirect( 4 ); // JOGL 2
> }
>
> Apparently creating tons of these inside the tight loops of
> Image.fill_image() and Image.empty_image() chokes the JVM. That's why it
> works when you step through slowly in the debugger -- it gives the JVM a
> chance to catch up.
>
> I'll create a bug report and a patch request for this. In the meantime, if
> you're building JOGL yourself you can make the above change in
> Type_Widget.java and it should let you proceed.
>
>
>
> _______________________________________________
> If you reply to this email, your message will be added to the discussion below:
>
http://jogamp.762907.n3.nabble.com/method-not-implemented-gluScaleImage-tp2304656p2324170.html> To start a new topic under jogamp, email
[hidden email]
> To unsubscribe from jogamp, visit
http://michael-bien.com/