[vtkusers] VTK 6.1 on Mac: from JDK 6 to JDK 8, compilation notes and changes in window handling
Sebastien Jourdain
sebastien.jourdain at kitware.com
Fri Apr 11 12:30:45 EDT 2014
So the JAWT management for Java is handle within that file:
$SRC/Wrapping/Java/vtkJavaAwt.h
And for the JOGL size issue, normally the vtkAbstractJoglComponent has a
glEventListener that has a reshape method which should be properly called.
Maybe you can find some information out there to make sure that method get
properly triggered for your use case.
Thanks guys for the support and help in improving that part,
Seb
On Fri, Apr 11, 2014 at 4:26 AM, Alexandre Dufour <adufour at pasteur.fr>wrote:
> Hi Marco, Sebastien, and other interested readers,
>
> I have switched from plain JAWT to JOGL following Sebastien's advice, and
> here are some updates (and a screenshot at
> http://postimg.org/image/tofkj7t3p):
>
> - On the test code I linked in my original post (left window in the
> screenshot), this works very well, and resizes automatically with the
> enclosing panel (it sits in a GridBagLayout) (what a relief not to be
> annoyed by the screen flickering of heavy weightiness anymore!)
>
> - Now on a different code (now trying to adapt our 3D viewer to use JOGL
> as well, right window in the screenshot), I experience precisely the issue
> you (Marco) described. The inner JOGL component (I'm using
> a vtkJoglPanelComponent for now) is only visible on the upper right-hand
> corner of its enclosing panel, i.e., a viewport of about 200x200 (could
> this be a default size?). Apart from that, you can guess through this tiny
> viewport that the rendering pipeline works (just like it was before the
> switch to JOGL). The vtkJoglPanelComponent.setSize() method is of no help
> here, and the panel sits in the center of a border layout JPanel. So I just
> thought I'd throw this at you guys while I keep searching for a (stupid)
> line to add or comment, in case it seems obvious to others.
>
> Many thanks for the help. Things are moving fast!
>
> Alexandre
>
> On 10 Apr 2014, at 22:48, Marco Sambin <m.sambin at gmail.com> wrote:
>
> Hi all,
>
> I made some experiments with VTK + JOGL in the recent past. I managed to
> make it work (more or less) on several platforms including Mac, but as far
> as I remember I had some issues with the size of the viewport on the output
> panel, and I abandoned the effort at that time: I did not have much time to
> spend on that topic; moreover, my VTK-based application was a Java Web
> Start application, and the overhead of including JOGL with it was not
> completely acceptable.
>
> I will probably come back to the "VTK + Mac" topic in the near future.
>
> In the release notes of Java 7u40 (
> http://www.oracle.com/technetwork/java/javase/2col/7u40-bugfixes-2007733.html)
> among other points, I can see:
>
> [...]
> (Bug fix): NSView-based implementation of sun.awt.EmbeddedFrame
> [...]
>
> So basically, recent versions of Java 7 offer again compatibility with
> "NSView JAWT embedding", which is the kind of JAWT embedding traditionally
> supported by VTK. The same holds true with the recently-released Java 8.
>
> Now, though I am not a Mac expert as a developer, from the information
> that I gathered, some changes will still need to be applied to VTK to make
> it work with the latest Java 7 / Java 8. For instance, the NSView-based
> subclass of sun.awt.EmbeddedFrame was previously "apple.awt.CEmbeddedFrame"
> (in Apple's Java 6, which worked with VTK), while now it should be "
> sun.lwawt.macosx.CViewEmbeddedFrame". Hence, at least some naming should
> be fixed. Then, it is likely that some methods signatures have slightly
> changed. Overall, it should be possible to make VTK work again "directly"
> with the latest Java 7 / Java 8, without the need for JOGL. This would be a
> very important step in my opinion.
>
> Again, although I am not a Mac expert as a developer, I am willing to
> dedicate some efforts on this in the near future, if some of you (maybe
> Seb?) could point me to the points in VTK where these JAWT Mac classes are
> referenced, in such a way I could maybe make some experiments with the
> re-introduced NSView-based classes.
>
> Thank you in advance for your feedback.
> Best regards,
>
> Marco Sambin
>
>
> On Wed, Apr 9, 2014 at 9:49 PM, Alexandre Dufour <adufour at pasteur.fr>wrote:
>
>> Thanks Sebastien for the fast and detailed answer.
>>
>> Indeed it seemed to me like a known issue (especially the light / heavy
>> weight one), but my searches didn't bring me far enough I guess.
>>
>> Will switch to OpenGL panels as soon as possible!
>>
>> Alexandre
>>
>> On 9 avr. 2014, at 20:09, Sebastien Jourdain <
>> sebastien.jourdain at kitware.com> wrote:
>>
>> Hi Alexandre,
>>
>> So your problem is a somewhat well known issue. Basically Oracle Java 7
>> and 8 changed their API with the Cocoa code which break the old rendering
>> technique used for Java.
>> To overcome that issue we provide a vtkJoglPanel / vtkJoglCanvas where
>> VTK handle the OpenGL code and we let the JOGL code do the graphical
>> integration.
>>
>> To enable them, you will need to get JOGL and build VTK with it with
>> additional options and paths.
>> But we are in the process of providing binaries of VTK for each platform
>> in an automatic manner. Unfortunately that process is not complete yet, but
>> you can download those binaries from the web by going to the VTK dashboard (
>> http://open.cdash.org/index.php?project=VTK) and downloading the
>> generated files by clicking on the yellow box.
>>
>> Also another known issue is that altair.kitware does not properly compile
>> the Java files, which means that it's generic vtk-6.0.1.jar does not
>> contains any class files.
>> But you can get that same file from any other platform.
>>
>> Here is how you can try those binaries:
>>
>> # Use maven to download the JOGL dependencies
>> $ mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get -DrepoUrl=
>> http://repo1.maven.org/maven2-Dartifact=org.jogamp.gluegen:gluegen-rt:2.0.2
>> $ mvn org.apache.maven.plugins:maven-dependency-plugin:2.1:get -DrepoUrl=
>> http://repo1.maven.org/maven2 -Dartifact=org.jogamp.jogl:jogl-all:2.0.2
>>
>> 1) Download and uncompress the native jar into a /.../lib directory.
>> 2) export DYLD_LIBRARY_PATH=/.../lib
>> 3) java -cp
>> vtk-6.1.jar:/Users/seb/.m2/repository/org/jogamp/jogl/jogl-all/2.0.2/jogl-all-2.0.2.jar:/Users/seb/.m2/repository/org/jogamp/gluegen/gluegen-rt/2.0.2/gluegen-rt-2.0.2.jar
>> vtk.sample.rendering.JoglConeRendering
>>
>> Hope that helps,
>>
>> Seb
>>
>>
>> On Wed, Apr 9, 2014 at 12:32 PM, Alexandre Dufour <adufour at pasteur.fr>wrote:
>>
>>> Hi everyone,
>>>
>>> We are using VTK via Java for 3D rendering purposes in the open-source
>>> Icy platform for bioimaging (http://icy.bioimageanalysis.org), and it
>>> has been a great experience so far (especially on Windows). Less so on Mac
>>> however, mostly due to Apple's custom JVM implementation (1.6) messing with
>>> the lightweight/heavyweight thingy, and the dramatic changes when switching
>>> to Java 1.8 (Oracle).
>>>
>>> -- The story starts when compiling VTK with Java bindings (after I
>>> installed Oracle's JDK 8 on Mavericks 10.9.2, Xcode 5.1). At runtime, vtk
>>> viewers that used to work under JDK 6 suddenly cause a bad crash (note that
>>> this also happened with Oracle's JDK 7):
>>> _NSJVMLoadLibrary: NSAddLibrary failed for /libjawt.dylib
>>> JavaVM FATAL: lookup of function JAWT_GetAWT failed. Exit
>>>
>>> -- I figured VTK probably wasn't properly talking to JDK 8, and noticed
>>> in CMakeLists that the JAVA_XXX flags were pointing to some weird bits of
>>> Java frameworks inside Xcode (in a MacOS10.9 resource bundle), therefore I
>>> changed them to:
>>> JAVA_AWT_INCLUDE_PATH /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include
>>>
>>>
>>>
>>> JAVA_AWT_LIBRARY /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/lib/libjawt.dylib
>>>
>>>
>>>
>>> JAVA_INCLUDE_PATH /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include
>>>
>>>
>>>
>>> JAVA_INCLUDE_PATH2
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/include/darwin
>>>
>>> -- This change wouldn't compile anymore, due to the following line
>>> (appears twice in Wrapping/Java/vtkJavaAwt.h):
>>> temp0->SetWindowId(dsi_mac->cocoaViewRef);
>>> (problem: the cocoaViewRef field does not exist anymore). Commenting
>>> this line however resumes compilation (but could cause the issue below).
>>>
>>> -- Once compiled, I took the sample code from this web site:
>>> http://www.particleincell.com/blog/2011/vtk-java-visualization/. Here
>>> is the outcome:
>>>
>>> -- -- Under JDK 6: the vtk panel nicely sits "inside" the main frame,
>>> where it is supposed to be (expected behaviour).
>>>
>>> -- -- Under JDK 8, the vtk panel opens in a new (native Mac) window
>>> entitled "Visualization Toolkit - Cocoa #1", while the main frame sits
>>> there with all other UI components, except the center zone is empty (it is
>>> like "sucked away" into the native window:)). Additionally, the Apple
>>> toolkit at runtime is complaining with the following console warning:
>>>
>>> 2014-04-09 19:05:10.178 java[2935:790f] Cocoa AWT: Not running on AppKit
>>> thread 0 when expected. (
>>> 0 libawt_lwawt.dylib 0x00000001255c3887 -[AWTWindow
>>> windowDidResignKey:] + 40
>>> 1 CoreFoundation 0x00007fff90f8ce0c
>>> __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
>>> 2 CoreFoundation 0x00007fff90e80a6d
>>> _CFXNotificationPost + 2893
>>> 3 Foundation 0x00007fff862bb7ba
>>> -[NSNotificationCenter postNotificationName:object:userInfo:] + 68
>>> 4 AppKit 0x00007fff89156760 -[NSWindow
>>> resignKeyWindow] + 702
>>> 5 AppKit 0x00007fff8905b363 -[NSWindow
>>> _changeKeyAndMainLimitedOK:] + 768
>>> 6 AppKit 0x00007fff89053856 -[NSWindow
>>> _makeKeyRegardlessOfVisibility] + 100
>>> 7 AppKit 0x00007fff890537c0 -[NSWindow
>>> makeKeyAndOrderFront:] + 29
>>> 8 libvtkRenderingOpenGL.jnilib 0x000000012c854d71
>>> _ZN20vtkCocoaRenderWindow13CreateAWindowEv + 2113
>>> 9 libvtkRenderingOpenGL.jnilib 0x000000012c855af8
>>> _ZN20vtkCocoaRenderWindow10InitializeEv + 344
>>> 10 libvtkRenderingOpenGL.jnilib 0x000000012c851e6d
>>> _ZN20vtkCocoaRenderWindow5StartEv + 29
>>> 11 libvtkRenderingCore.jnilib 0x0000000129db9fad
>>> _ZN15vtkRenderWindow14DoStereoRenderEv + 29
>>> 12 libvtkRenderingCore.jnilib 0x0000000129db9f6c
>>> _ZN15vtkRenderWindow10DoFDRenderEv + 1612
>>> 13 libvtkRenderingCore.jnilib 0x0000000129db98fd
>>> _ZN15vtkRenderWindow10DoAARenderEv + 1837
>>> 14 libvtkRenderingCore.jnilib 0x0000000129db8ec2
>>> _ZN15vtkRenderWindow6RenderEv + 2418
>>> 15 libvtkRenderingCoreJava.jnilib 0x0000000129b2f291
>>> Java_vtk_vtkRenderWindow_Render_19 + 49
>>> 16 ??? 0x000000010ec0a66e 0x0 +
>>> 4542473838
>>> 17 ??? 0x000000010ebfd2e0 0x0 +
>>> 4542419680
>>>
>>>
>>> In both cases, the viewers behave identically.
>>>
>>> I apologise for the long post, but I assume this is sufficiently
>>> complete to describe and reproduce the problem.
>>> Has anyone experienced this lately? Any hints on why the behaviour is
>>> different? I could not find any similar issue on the forum...
>>>
>>> Many thanks for your attention, and looking forward to updates on the
>>> Mac port!
>>>
>>> Best wishes
>>> Alexandre
>>>
>>> ---
>>> Alexandre Dufour, Ph.D.
>>> Institut Pasteur - Bio Image Analysis Group
>>> 25, rue du Docteur Roux, Paris, France
>>> Research: http://www.bioimageanalysis.org/dufour
>>> Software: http://icy.bioimageanalysis.org
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20140411/99f95b81/attachment.html>
More information about the vtkusers
mailing list