mac and linux testers req.

arielm · January 31, 2007, 11:52pm

PLEASE SCROLL DOWN AND LOOK FOR BOLD-RED TEXT TO FIND UPDATED TEST-CASE.
THE LATEST TEST CASE APPEARS IN THE NEXT THREAD PAGE

I’m about to publish a new series of webstart experiments at http://www.chronotext.org and I would like to be sure everything runs as intended (there might be some issues on mac)

Here’s a simple set of question/answers for those who would like to help testing:

q1) what is your os? (e.g. mac ppc | mac intel | linux 32bit | linux 64bit)

TEST 1)
http://www.chronotext.org/mapping/Tokyo_EN.jnlp
q2) can you see a photo of a building with camouflage texture and text flowing on the facade? (see screenshot below)
q3) is it possible to pan over the image by mouse-dragging?
q4) does it zoom-in and out when using the mousewheel?

TEST 2)
http://www.chronotext.org/mapping/Branly_Freestyle.jnlp
q5) can you see an animation which begins like in the screenshot below?

Thanks!
Ariel

kappa · February 1, 2007, 12:00am

runs fine here on linux32

kbr · February 1, 2007, 4:22am

Mac Intel (Mac Mini, Intel Integrated Graphics)

Yes.

This is really cool stuff! Nice mix of 3D graphics and real-world imagery.

arielm · February 1, 2007, 8:53am

Thank you guys for the encouraging results…

Currently, I still have problems on mac ppc’s. Here are 2 negative reports I received for that platform:

the building is showing, but no text and texture flow
nothing works (blackout…)

Any other mac (ppc) potential testers?

c_lilian · February 1, 2007, 9:04am

Hi,

crash on Mac PPC (OS X 10.3, latest java 1.4)

Lilian

javax.media.opengl.GLException: java.lang.OutOfMemoryError: Direct buffer memory
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:266)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:256)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
	at com.sun.opengl.util.Animator.display(Animator.java:144)
	at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
	at java.lang.Thread.run(Thread.java:552)
Caused by: java.lang.OutOfMemoryError: Direct buffer memory
	at java.nio.Bits.reserveMemory(Bits.java:634)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:95)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:285)
	at com.sun.opengl.util.BufferUtil.newByteBuffer(BufferUtil.java:65)
	at com.sun.opengl.util.BufferUtil.newFloatBuffer(BufferUtil.java:82)
	at texture6.f.b(Unknown Source)
	at texture6.f.d(Unknown Source)
	at texture6.f.a(Unknown Source)
	at texture6.h.a(Unknown Source)
	at texture6.h.a(Unknown Source)
	at overlay.Tokyo_12.a(Unknown Source)
	at overlay.Tokyo_12.c(Unknown Source)
	at common.g.display(Unknown Source)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:298)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:179)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:478)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

c_lilian · February 1, 2007, 9:06am

oh, and for number 2, there’s an animation, but no textures.

(no stack trace this time)

arielm · February 1, 2007, 9:43am

Lilian,

Thank you so much for your help. It’s very helpful to see a stacktrace of the problem (now I can see the issue is related to texture-loading…)

However, I was as stupid as using an obfuscated version of the code, and therefore I’m unable to find out where the problem lies

Anyway: I now uploaded a corrected version: could you retry to reproduce the same kind of error?
http://www.chronotext.org/mapping/Tokyo_FR.jnlp

(un tres gros merci d’avance!..)
Ariel

c_lilian · February 1, 2007, 10:13am

et voila !


avax.media.opengl.GLException: java.lang.OutOfMemoryError: Direct buffer memory
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:266)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:256)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
	at com.sun.opengl.util.Animator.display(Animator.java:144)
	at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
	at java.lang.Thread.run(Thread.java:552)
Caused by: java.lang.OutOfMemoryError: Direct buffer memory
	at java.nio.Bits.reserveMemory(Bits.java:634)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:95)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:285)
	at com.sun.opengl.util.BufferUtil.newByteBuffer(BufferUtil.java:65)
	at com.sun.opengl.util.BufferUtil.newFloatBuffer(BufferUtil.java:82)
	at texture6.ZFont.addSlot(ZFont.java:975)
	at texture6.ZFont.getVertices(ZFont.java:935)
	at texture6.ZFont.addSequenceCharacter(ZFont.java:1006)
	at texture6.TextureRectangle.drawLine(TextureRectangle.java:152)
	at texture6.TextureRectangle.drawText(TextureRectangle.java:86)
	at overlay.Tokyo_12.rectangle(Tokyo_12.java:472)
	at overlay.Tokyo_12.display(Tokyo_12.java:319)
	at common.Sketch.display(Sketch.java:273)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:298)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:179)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:478)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:234)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:178)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:170)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

Lilian

bleb · February 1, 2007, 11:11am

Looks like the same thing here on linux32:
(I’m running with 2GB of Ram and 256MB of VRAM btw)

Java Web Start 1.5.0_08
Using JRE version 1.5.0_08 Java HotSpot(TM) Client VM
User home directory = /home/ryanm
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
0-5: set trace level to <n>
----------------------------------------------------
Exception in thread "Thread-9" javax.media.opengl.GLException: java.lang.OutOfMemoryError: Direct buffer memory
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:266)
	at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:256)
	at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
	at com.sun.opengl.util.Animator.display(Animator.java:144)
	at com.sun.opengl.util.Animator$MainLoop.run(Animator.java:181)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.OutOfMemoryError: Direct buffer memory
	at java.nio.Bits.reserveMemory(Bits.java:632)
	at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:95)
	at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
	at com.sun.opengl.util.BufferUtil.newByteBuffer(BufferUtil.java:65)
	at com.sun.opengl.util.BufferUtil.newFloatBuffer(BufferUtil.java:82)
	at texture6.ZFont.addSlot(ZFont.java:975)
	at texture6.ZFont.getVertices(ZFont.java:935)
	at texture6.ZFont.addSequenceCharacter(ZFont.java:1006)
	at texture6.TextureRectangle.drawLine(TextureRectangle.java:152)
	at texture6.TextureRectangle.drawText(TextureRectangle.java:86)
	at overlay.Tokyo_12.rectangle(Tokyo_12.java:472)
	at overlay.Tokyo_12.display(Tokyo_12.java:319)
	at common.Sketch.display(Sketch.java:273)
	at com.sun.opengl.impl.GLDrawableHelper.display(GLDrawableHelper.java:78)
	at javax.media.opengl.GLCanvas$DisplayAction.run(GLCanvas.java:281)
	at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:194)
	at javax.media.opengl.GLCanvas$DisplayOnEventDispatchThreadAction.run(GLCanvas.java:298)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

Test 2 works fine though.

arielm · February 1, 2007, 12:03pm

Thank you Bleb, and Lilian too again (what’s your system detail btw?)

Actually, instead of a texture-loading problem, it looks like a NIO “direct buffer” memory allocation issue.
Strange, since I’m only allocating something like 80 small FloatBuffer’s (to be used for vertex-arrays…) and the total amount of memory required for all of them together is around 400K!

How can a modern computers fail on such a tiny request?

Could it be related to the fact that before-hand, I’m transfering a big image to opengl?
At some point, I’m “wrapping” a ByteBuffer around the underlying java-heap int array of a 800x600 BufferedImage in order to do the transfer, but right after, the BufferedImaged is flushed, nulled as well as the wrapping ByteBuffer reference.

Maybe the system is just not properly deallocating the 800x600x4x4 ByteBuffer in question?

[s][b]UPDATED TEST CASE:

THE 4 FOLLOWING TINY WEBSTART APPS ARE THE ONES TO TEST…

MAC AND UNIX TESTERS WELCOME

(SORRY TO SHOUT IN BOLD-RED, BUT IT WILL HELP NEWCOMERS TO THIS THREAD TO SEE WHERE THE ACTION TAKES PLACE)[/b][/s]

THE LATEST TEST CASE APPEARS IN THE NEXT THREAD PAGE

TEST B1)
www.chronotext.org/mapping/DEBUG_1.jnlp
With the help of System.gc(), you should see a building photo, with texture and text flowing…

TEST B2)
www.chronotext.org/mapping/DEBUG_2.jnlp
You should see the same as previously, except that the background photo is at a lower resolution (400x300 instead of 800x600)

TEST B3)
www.chronotext.org/mapping/DEBUG_3.jnlp
You should see texture and text flowing on a plain gray background…

TEST B4)
www.chronotext.org/mapping/DEBUG_4.jnlp
You should see text flowing on a plain gray background…

Thanks! (if none of this tests work, I’ll start to think that windows indeed rocks

Orangy_Tang · February 1, 2007, 12:55pm

Both b1 and b4 fail for me:

javax.media.opengl.GLException: java.lang.reflect.InvocationTargetException
	at javax.media.opengl.GLCanvas.disableBackgroundErase(GLCanvas.java:352)
	at javax.media.opengl.GLCanvas.addNotify(GLCanvas.java:154)
	at java.awt.Container.addImpl(Unknown Source)
	at java.awt.Container.add(Unknown Source)
	at common.Sketch.setup(Sketch.java:90)
	at overlay.Tokyo_12_DEBUG4.main(Tokyo_12_DEBUG4.java:98)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
	at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
	at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at javax.media.opengl.GLCanvas.disableBackgroundErase(GLCanvas.java:350)
	... 16 more
Caused by: java.lang.UnsatisfiedLinkError: disableNativeBackgroundErase
	at sun.awt.windows.WCanvasPeer.disableNativeBackgroundErase(Native Method)
	at sun.awt.windows.WCanvasPeer.disableBackgroundErase(Unknown Source)
	at sun.awt.windows.WToolkit.disableBackgroundErase(Unknown Source)
	... 21 more

WinXP, Java 1.5.0_10

c_lilian · February 1, 2007, 1:09pm

the 4 tests fail here (mac g5 1.8Ghz os x 10.3, 1Gb RAM)

Lilan

CommanderKeith · February 1, 2007, 1:14pm

Wow! Amazing work!

Windows XP, Java 6 and all work great!

arielm · February 1, 2007, 1:30pm

Glad you like… more of the same kind here: http://www.chronotext.org/mapping/
(Please note that it’s not an “official” link for now, as long as all the bugs are not solved…)

Orangy,
Thanks for your bug report, eventhough I don’t think it’s a big threat for most users:
Somehow, it happens when a GLCanvas is added to an AWT frame, and from what google have to save on disableNativeBackgroundErase it seems to be related to the presence of several concurent versions of Java on the same system…

Lilian:
Thanks, and not so bad news: at least, now, I can think it’s not an “out of memory due to unproper deallocation issue” but more like a mysterious unability to allocate ~80 small NIO FloatBuffer’s…

To be further investigated (hoping to find a real mac in my vicinity…)

Orangy_Tang · February 1, 2007, 1:41pm

I don’t think it’s very nice that you won’t fix a known bug just because you don’t think it’ll affect many people. Given that about 5 or 6 people here have tried it, and it’s cropped up once that would suggest it’s a little more common than you think. Ignoring 20% of your users isn’t very nice.

c_lilian · February 1, 2007, 1:48pm

the disableBackgroundErase() bug should be fixed by using the latest RC of jogl : it happens when the user has a jre 1.5.0_10

(I had the same problem last month on my game)

Lilian

arielm · February 1, 2007, 1:57pm

[quote=“c_lilian,post:16,topic:29241”]
good news! (and now I can feel like being a nice guy again ;))

kbr · February 1, 2007, 5:34pm

There’s a really nasty longstanding problem with direct buffer allocations where small buffer allocations can be rounded up to 4K (or the machine’s page size) on some OSs. The root cause for this is the New I/O subsystem’s trying to support fast file transfers or similar operations to these Buffers and their needing to be a certain minimum size. Anyway, the workaround for this is to allocate your direct Buffers in chunks and split them up manually yourself. This might address the exhaustion of direct buffer memory.

arielm · February 1, 2007, 7:40pm

Bingo, Ken, I think that could be the problem! (I’m allocating around 80 buffers, sized either 16K or 24K each, and it makes problems on some mac-ppc and linux boxes…)

Do you have a more precise reference about this indeed really nasty bug?

kbr · February 1, 2007, 9:02pm

Sorry, I don’t. You might want to try querying Sun’s bug database. I raised this issue a long time ago but at this point it’s so old that it’s probably better to just know about and work around it.