mac and linux testers req.

OpenGL Development JOGL Development
#21

Yep… so finally: I updated my code to avoid allocation of small NIO buffers…

[b]UPDATED TEST-CASE

A FEW MORE MAC AND LINUX TESTS WANTED, THANKS![/b]

TEST C1)
http://www.chronotext.org/mapping/Tokyo_EN.jnlp
q1) can you see a photo of a building with camouflage texture and text flowing on the facade (as screenshot below)?

TEST C2)
http://www.chronotext.org/mapping/Branly.jnlp
q2) can you see a photo of a building with camouflage texture and text flowing on the facade (as screenshot below)?

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

#22

All three tests are running well on both a Mac Mini (Intel CPU and Intel Integrated Graphics) as well as a Mac G5 (dual-CPU, NVidia GeForce 6800 GT), both running 10.4.8. They look really nice. Panning and zooming with the scroll wheel work fine.

#23

Finger crossed while hoping for a positive confirmation by Lilian and Bleb :stuck_out_tongue:

#24

Hi,

sorry : C1, C2 : black screen, no stack trace
C3 : same as before (missing bottom texture)

Lilian :slight_smile:

#25

I’m working in windows-land today :frowning: , so don’t hold your breath for any reports from me

#26

Smooth demos!

Linux 2.6.19
xorg 11R7.0
KDE 3.5
nvidia GF 7900 GS

(Dell XPS M1710)

All ok :slight_smile:

#27

However, testing these on my MacBook Pro (Intel, ATI X1600 128MB, OS X 10.4.8 ) some tests fail…

C1: Can see the static image, but no mouse interaction, and app freezes (kill -s KILL needed to stop)
C2: Same as C1
C3: Seems to work OK, but unable to use mouse to pan/zoom

java version “1.5.0_06”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)

#28

Back in Linux today:

C1: Same as krigun - static image that isn’t redrawn when another window moves infront of it, no animation, nothing in the console, had to use xkill to get rid of it.
C2: Same as C1
C3: Seems to work, not terribly smooth though.

#29

Ouch! (and thank you again guys :slight_smile:

I think I have fixed many different issues during the last few days, but one of them is really nasty: freeze with no stack-trace on 50% of the world’s macs and a few linux boxes…

Unfortunately, in term of bug hunting / solving: it works perfectly on windows (which I use) and the only real mac I found around here!

I can tell it is an issue related to my text-engine, which deals a lot with NIO buffers (for texture handling as well as vertex-array management…)

I went again over everything and made a kamikaze reorganization (minimizing the role of NIO buffers) in the hope it will help.

If some of you still have the patience to make a test: http://www.chronotext.org/mapping/Tokyo_EN.jnlp

In addition, within the coming days, I should post a simplified test-case in order to “isolate” the problematic issue, since I think it can be helpful for many of us to understand what works well on all the platforms and what not like in this case…

Thanks,
Ariel

#30

Hmm, not working (black windows), no stacktraces…

Lilian

#31

Tested on the MacBook as described in my earlier post, and still getting the same behaviour. Sorry. Can’t really see whats wrong either, since there is no evidence of an exception. The app just stops responding.

#32

Yep, same behaviour as before. Could you make an executable jar version so we can check for deadlocks?

#33

Great Idea! Here’s a self-executable jar file:

http://www.chronotext.org/lab/DEBUG1.jar (363K)

I added some System.out progress messages that should be helpful to isolate the issue.

The jar’s manifest is as follows:
Class-Path: jogl.zip gluegen-rt.jar Main-Class: debug3.Tokyo_15_DEBUG1

Therefore, on my system, I put the jar in a directory together with:

  • jogl.zip
  • gluegen-rt.jar
  • jogl.dll
  • jogl_awt.dll
  • gluegen-rt.dll

In order to see the output, I launch with something like:
java -classpath DEBUG1.jar debug3.Tokyo_15_DEBUG1 >output.txt

Supposing everything runs without bugs, the output looks like:
Tokyo_15.init(): BEGIN... Tokyo_15.init(): TEXTURE LOADED Tokyo_15.init(): FONT CREATION BEGIN...END Tokyo_15.init(): BACKGROUND LOADED Tokyo_15.init(): END Tokyo_15.display(): FRAME 1 ZFont.allocate: BEGIN...END ZFont.initTexture: ENTITY '83' BEGIN...END ... ZFont.initTexture: ENTITY '80' BEGIN...END Tokyo_15.display(): FRAME 2

Thanks!

#34

FYI, you should be able to use the jstack program that ships with the JDK to get a thread dump from an arbitrary deadlocked process containing the JVM. You just need to figure out the process ID. There is a jps command which should help with this as well.

#35

Sorry for the delay, find attached the stack trace. I couldn’t see anything obvious, but that’s maybe just me

#36

thank you bleb, definitely helpful!