[vtkusers] VTK6 + Java7 on Mac: offscreen rendering?
Sebastien Jourdain
sebastien.jourdain at kitware.com
Fri Sep 13 11:01:29 EDT 2013
Thanks Marco,
This is awesome!
Now I have a path to go forward on that bug. I just have to check around me
to see what will be a valid fix.
But your investigation is very valuable.
Thanks again,
Seb
On Fri, Sep 13, 2013 at 10:22 AM, Marco Sambin <m.sambin at gmail.com> wrote:
> Hi all,
>
> analyzing and debugging more in depth the issues I was experiencing with
> VTK 6.1 (GIT) and rendering from Java through JOGL, I made some interesting
> discoveries. I'll share them on this list, in the hope this can help
> improving VTK (be prepared, it's a long post ;-)):
>
> 1) When using JOGL on Windows (vtkJoglCanvasComponent), as soon as I
> pressed/dragged with my mouse upon a vtkImagePlaneWidget, my whole
> application was freezed, and the CPU usage went up to 25%. I discovered
> this was due to a "vtkClearOpenGLErrors()" call in the rendering pipeline,
> which was iterating indefinitely in its "while" loop. Not sure what was the
> real cause of this, did not have the time to debug in detail. I worked
> around the problem by setting the VTK_REPORT_OPENGL_ERRORS option to
> "false" on CMake (which forces the implementation of vtkClearOpenGLErrors()
> to be empty). After this change (and another minor change) VTK + JOGL on
> Windows started behaving exactly as on Linux and Mac OS X, i.e., working
> fine on initial rendering and programmatic changes to the 3D view issued
> from Java code, but immediately crashing the JVM as soon as I
> pressed/dragged with my mouse over the vtkImagePlaneWidget.
> At this point, I put my VS debugger at work, in order to better understand
> what was happening on Mac and Linux (and now also on Windows).
>
> 2) I discovered that the ultimate cause of the crash is that whenever a
> "this->Interactor->Render();" call is issued directly by the
> vtkImagePlaneWidgets native code (e.g., in the
> vtkImagePlaneWidget::StartCursor() method), this specific rendering context
> is obtaining NULL pointers for all OpenGL functions grouped under
> "vtkgl::". I am not an OpenGL expert, but I think that it means that the
> initial "this->Interactor->Render();" is issued in a moment where no valid
> OpenGL context exists.
> More specifically, when pressing the left mouse button on the
> vtkImagePlaneWidget, the crash was happening
> in vtkPixelBufferObject::CreateBuffer(), on the line "vtkgl::GenBuffers(1,
> &ioBuf);", due to the fact the "vtkgl::GenBuffers" function point was NULL.
>
> 3) Once I discovered what was causing the crash (actually, the ultimate
> cause of the invalid OpenGL context still needs to be identified), I tried
> to figure out a workaround. My workaround was to subclass
> vtkImagePlaneWidget with my own vtkModifiedImagePlaneWidget, overriding
> several methods and removing all calls to "this->Interactor->Render();".
> Instead, I listened to the various events ("InteractionEvent",
> "WindowLevelEvents", etc.) from my Java code, and issued Render() calls on
> the vtkJoglCanvasComponent (i.e., from Java code) instead. This fixed the
> crash on all OS (Windows, Mac OS X, and Linux)! So now I have a working
> implementation using VTK + Java 7 + JOGL on Mac as well!
>
> This "trick" works for me, but I think it would be better to identify the
> original cause for these invalid OpenGL contexts. Maybe someone already
> knows the cause of this issue.
>
> By the way, I think the issue of invalid OpenGL contexts when invoking
> Interactor->Render() from native widget code is present independently of
> JOGL: in fact, on Linux I had crashes for instance when setting
> Window/Level on the vtkImagePlaneWidgets (which in turns calls
> Interactor->Render()) even without using JOGL. All the crashes were
> resolved by replacing the Interactor->Render() calls (native code) with
> vtkCanvas.Render() calls from Java code (in the event listeners).
>
> Comments are appreciated.
>
> Thanks in advance and best regards,
>
> Marco Sambin
>
>
> On Thu, Sep 12, 2013 at 4:11 PM, Sebastien Jourdain <
> sebastien.jourdain at kitware.com> wrote:
>
>> Hi Marco,
>>
>> As an Open Source company, Kitware provide the infrastructure for the
>> community to use and benefit from our set of toolkit freely. But any new
>> feature or enhancement has a cost and that's why the funding aspect is
>> driving the evolution and enhancements of VTK/ParaView/ITK/CMake.
>>
>> It just happen that a community member was willing to contribute to the
>> Java aspect of VTK for its personal interest, but for the good of the
>> community the work is now available to anyone.
>>
>> So getting back to your question on a better integration of VTK with Java
>> on Mac without JOGL, that will depend on the will of the community and the
>> amount of money they could put toward such a goal. Right now, it seems that
>> we won't have any funding toward that goal. But that could change.
>>
>> Seb
>>
>>
>>
>> On Thu, Sep 12, 2013 at 2:24 AM, Marco Sambin <m.sambin at gmail.com> wrote:
>>
>>> Ok Seb,
>>>
>>> I understand, and thank you for your feedback.
>>> We are really eager to see a VTK version working fine on Mac with Java
>>> 7. Cross-platform compatibility is in my opinion a very appealing aspect of
>>> VTK.
>>>
>>> One question: regarding VTK compatibility with Java 7 on Mac, will JOGL
>>> be the final and only solution, or you have plans to add "direct"
>>> compatibility inside VTK in the future?
>>>
>>> Thanks and best regards,
>>>
>>> Marco
>>> Il giorno 11/set/2013 18:44, "Sebastien Jourdain" <
>>> sebastien.jourdain at kitware.com> ha scritto:
>>>
>>> Hum,
>>>>
>>>> thanks Marco for your help but it seems to be a tricky bug...
>>>> I'm pretty booked for a while on other projects and I'm not sure I'll
>>>> be able to address those issue in the coming month.
>>>> But I'll keep that in mind and try to come up with a fix when I'll have
>>>> a chance to get back to it.
>>>>
>>>> Thanks again,
>>>>
>>>> Seb
>>>>
>>>>
>>>> On Wed, Sep 11, 2013 at 12:22 PM, Marco Sambin <m.sambin at gmail.com>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've just made the same test with vtkJoglCanvasComponent on Linux
>>>>> (Arch Linux 64-bit, Java 7u21 64-bit, Macbook Pro i5 with NVIDIA native
>>>>> video drivers), and I obtained the same exact behavior as on Mac OS X
>>>>> (described in my previous post): in summary everything works quite fine,
>>>>> but the JVM crashes as soon as I mouse-press or drag over the widget itself.
>>>>>
>>>>> Here is the crash dump I obtained on Linux, which is maybe even more
>>>>> useful than the previous one:
>>>>>
>>>>> ===================
>>>>> [...]
>>>>> Stack: [0x00007fcecd37e000,0x00007fcecd47f000],
>>>>> sp=0x00007fcecd47b6e0, free space=1013k
>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>> C=native code)
>>>>> C [libvtkRenderingOpenGL-6.1.so+0x113817] vtkUpload3D<unsigned
>>>>> char>::Upload(void*, unsigned char*, unsigned int*, int, long long*, int,
>>>>> int*)+0x69
>>>>>
>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0
>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1
>>>>> j
>>>>> vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227
>>>>> j
>>>>> java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54
>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81
>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581
>>>>> j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
>>>>> j
>>>>> java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V+41
>>>>> j
>>>>> java.awt.EventQueue.access$200(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V+3
>>>>> j java.awt.EventQueue$3.run()Ljava/lang/Void;+12
>>>>> j java.awt.EventQueue$3.run()Ljava/lang/Object;+1
>>>>> v ~StubRoutines::call_stub
>>>>> J
>>>>> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>> j
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+28
>>>>> j
>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+6
>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Void;+11
>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Object;+1
>>>>> v ~StubRoutines::call_stub
>>>>> J
>>>>> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>> J java.awt.EventDispatchThread.pumpOneEventForFilters(I)V
>>>>> j
>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35
>>>>> j
>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
>>>>> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
>>>>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
>>>>> j java.awt.EventDispatchThread.run()V+9
>>>>> v ~StubRoutines::call_stub
>>>>>
>>>>> [...]
>>>>> ===================
>>>>>
>>>>> I am looking forward to hearing your comments.
>>>>> Thanks in advance and best regards,
>>>>>
>>>>> Marco Sambin
>>>>>
>>>>>
>>>>> On Wed, Sep 11, 2013 at 4:34 PM, Marco Sambin <m.sambin at gmail.com>wrote:
>>>>>
>>>>>> Hi Seb,
>>>>>>
>>>>>> thanks for your feedback.
>>>>>>
>>>>>> I've just tested on Mac (Mac OS X 10.8.4, Java 7u25, Macbook Pro i5),
>>>>>> and here is what happens:
>>>>>>
>>>>>> - I am able to correctly display the 3D scene with the 3
>>>>>> vtkImagePlaneWidgets (for the first time on VTK + Mac OS X + Java 7, and
>>>>>> that's good! :-)).
>>>>>>
>>>>>> - I am able to interact with the 3D scene (i.e., move/rotate the
>>>>>> camera) when dragging my mouse on the 3D scene OUTSIDE the
>>>>>> vtkImagePlaneWidgets.
>>>>>>
>>>>>> - If I press or drag with the mouse INSIDE the vtkImagePlaneWidgets,
>>>>>> then the JVM crashes. Here is a relevant (I hope) fragment of the JVM crash
>>>>>> dump:
>>>>>>
>>>>>> =================
>>>>>> [...]
>>>>>>
>>>>>> Stack: [0x000000013d09c000,0x000000013d19c000],
>>>>>> sp=0x000000013d197fa0, free space=1007k
>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>>>>>> C=native code)
>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x857b7]
>>>>>> _ZN11vtkUpload3DIhE6UploadEPvPhPjiPxiPi+0xd5
>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x81834]
>>>>>> _ZN20vtkPixelBufferObject8Upload3DEiPvPjiPxiPi+0x9a8
>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x7a085]
>>>>>> _ZN16vtkOpenGLTexture4LoadEP11vtkRenderer+0x1a7d
>>>>>> C [libvtkRenderingFreeType-6.1.1.dylib+0x1b8c6]
>>>>>> _ZN12vtkTextActor13RenderOverlayEP11vtkViewport+0x5a
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7bd38]
>>>>>> _ZN11vtkRenderer14UpdateGeometryEv+0x114
>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x6a3aa]
>>>>>> _ZN17vtkOpenGLRenderer12DeviceRenderEv+0xea
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7b5c1]
>>>>>> _ZN11vtkRenderer6RenderEv+0x26f
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7aacc]
>>>>>> _ZN21vtkRendererCollection6RenderEv+0x5a
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x824c3]
>>>>>> _ZN15vtkRenderWindow14DoStereoRenderEv+0x83
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x8241b]
>>>>>> _ZN15vtkRenderWindow10DoFDRenderEv+0x38d
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x8206a]
>>>>>> _ZN15vtkRenderWindow10DoAARenderEv+0x43a
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x81905]
>>>>>> _ZN15vtkRenderWindow6RenderEv+0x149
>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x85673]
>>>>>> _ZN25vtkRenderWindowInteractor6RenderEv+0x27
>>>>>> C [libvtkCommonCore-6.1.1.dylib+0x59561]
>>>>>> _ZN18vtkCallbackCommand7ExecuteEP9vtkObjectmPv+0x21
>>>>>> C [libvtkCommonCore-6.1.1.dylib+0xb60bc]
>>>>>> _ZN16vtkSubjectHelper11InvokeEventEmPvP9vtkObject+0x39a
>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0
>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1
>>>>>> j
>>>>>> vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227
>>>>>> j
>>>>>> java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54
>>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81
>>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581
>>>>>>
>>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0
>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1
>>>>>> j
>>>>>> vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227
>>>>>> j
>>>>>> java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54
>>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81
>>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581
>>>>>> J
>>>>>> java.awt.EventQueue.access$200(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V
>>>>>> J java.awt.EventQueue$3.run()Ljava/lang/Object;
>>>>>> v ~StubRoutines::call_stub
>>>>>> J
>>>>>> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>>> J
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>>> j
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+6
>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Void;+11
>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Object;+1
>>>>>> v ~StubRoutines::call_stub
>>>>>> J
>>>>>> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>>> J
>>>>>> java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;
>>>>>> j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+73
>>>>>> j java.awt.EventDispatchThread.pumpOneEventForFilters(I)V+245
>>>>>> j
>>>>>> java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35
>>>>>> j
>>>>>> java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
>>>>>> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
>>>>>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
>>>>>> j java.awt.EventDispatchThread.run()V+9
>>>>>> v ~StubRoutines::call_stub
>>>>>>
>>>>>> [...]
>>>>>> =================
>>>>>>
>>>>>> Please let me know if this tells you something useful, and if I can
>>>>>> be of further help.
>>>>>>
>>>>>> I will now make some tests on Linux as well, and will report back to
>>>>>> you.
>>>>>>
>>>>>> Thanks and best regards,
>>>>>>
>>>>>> Marco Sambin
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 11, 2013 at 6:10 AM, Sebastien Jourdain <
>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>
>>>>>>> Hi Marco,
>>>>>>>
>>>>>>> You may have found an issue that I missed on Windows. For some
>>>>>>> reason the event forwarding to the interactor was freezing the application.
>>>>>>> Therefore, I took the same route as the old vtkPanel by using a direct
>>>>>>> camera manipulation (as an option for windows app).
>>>>>>> Unfortunately 3d widget do expect interactor events. Therefore, to
>>>>>>> properly work, we will have to figure out how to properly solve the issue
>>>>>>> that you discovered.
>>>>>>>
>>>>>>> Do you mind testing that on Mac and letting me know if the issue
>>>>>>> exist?
>>>>>>>
>>>>>>> Moreover, I should make a proper announcement to the mailing list
>>>>>>> but I've merged into master a couple days ago a branch that let CMake do a
>>>>>>> proper packaging of VTK for Java if the proper options are provided.
>>>>>>>
>>>>>>> Seb
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 10, 2013 at 1:06 PM, Marco Sambin <m.sambin at gmail.com>wrote:
>>>>>>>
>>>>>>>> Hi Seb,
>>>>>>>>
>>>>>>>> thanks for your feedback.
>>>>>>>>
>>>>>>>> The example was indeed useful: I am now using
>>>>>>>> vtkJoglCanvasComponent (got current VTK 6.1 from GIT) as my rendering
>>>>>>>> component, and now I am rendering my 3D view through JOGL, after loading a
>>>>>>>> bunch of JARs and native libs.
>>>>>>>>
>>>>>>>> Rendering seems to work quite fine on Windows (I am testing on this
>>>>>>>> OS first of all, then I will move to Mac later), and I can see my 3
>>>>>>>> vtkImagePlaneWidgets in the 3D view. Also, if I programmatically
>>>>>>>> change vtkImagePlaneWidgets' plane positions or orientations, and then call
>>>>>>>> Render() on my vtkJoglCanvasComponent, the 3D view is updating fine.
>>>>>>>>
>>>>>>>> On the other side, if I try to interact with the widgets in the 3D
>>>>>>>> view through the mouse, my Java application immediately and completely
>>>>>>>> freezes, and the CPU goes up to 25%.
>>>>>>>>
>>>>>>>> Can you guess what is causing this behavior? Is interaction with
>>>>>>>> widgets supposed to work when using JOGL?
>>>>>>>>
>>>>>>>> I have not tested this, but I have the impression that the
>>>>>>>> application freezes when the widget's native code calls
>>>>>>>> "this->Interactor->Render();". Will this call be somehow "intercepted" by
>>>>>>>> JOGL, and become equivalent to calling Render() on the
>>>>>>>> vtkJoglCanvasComponent (which, on the other side, seems to work fine)?
>>>>>>>>
>>>>>>>> Thanks again for your feedback: this path seems really promising,
>>>>>>>> and may open a whole new world with using VTK from Java.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Marco
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Sep 9, 2013 at 5:33 PM, Sebastien Jourdain <
>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Marco,
>>>>>>>>>
>>>>>>>>> you will have to use another class. But you will have the same
>>>>>>>>> integration capability.
>>>>>>>>>
>>>>>>>>> Look
>>>>>>>>> at src/VTK/Wrapping/Java/vtk/sample/rendering/JoglConeRendering.java for
>>>>>>>>> more details.
>>>>>>>>>
>>>>>>>>> Seb
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Sep 9, 2013 at 10:37 AM, Marco Sambin <m.sambin at gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> Hi Seb,
>>>>>>>>>>
>>>>>>>>>> this is great news, and I will give it a try!
>>>>>>>>>> One question: will I be able to keep using vtkCanvas as a Java
>>>>>>>>>> panel class, or rather shall I move to something different?
>>>>>>>>>> Thanks again for your feedback.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> Marco Sambin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 9, 2013 at 2:45 PM, Sebastien Jourdain <
>>>>>>>>>> sebastien.jourdain at kitware.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Marco,
>>>>>>>>>>>
>>>>>>>>>>> you won't be able to rely on offscreen rendering on Mac to
>>>>>>>>>>> properly handle the issue you are trying to overcome.
>>>>>>>>>>>
>>>>>>>>>>> Although, a couple of weeks ago, I've pushed a new set of
>>>>>>>>>>> classes that works on Mac OS X and Java7 (and on the other of the
>>>>>>>>>>> platforms).
>>>>>>>>>>> Those classes rely on JOGL to do the rendering. So if adding
>>>>>>>>>>> JOGL as a dependency is not an issue, you can directly use those.
>>>>>>>>>>>
>>>>>>>>>>> For that you will need to get VTK/master from git and when you
>>>>>>>>>>> build VTK, you will have to turn ON that component. Moreover if you already
>>>>>>>>>>> download JOGL/GLUGEN using maven, CMake should find the appropriate jars
>>>>>>>>>>> for you.
>>>>>>>>>>> Otherwise you will need to specify their paths.
>>>>>>>>>>>
>>>>>>>>>>> Here is the dependency for Maven.
>>>>>>>>>>>
>>>>>>>>>>> + <dependency>
>>>>>>>>>>> + <groupId>org.jogamp.jogl</groupId>
>>>>>>>>>>> + <artifactId>jogl-all-main</artifactId>
>>>>>>>>>>> + <version>2.0.2</version>
>>>>>>>>>>> + </dependency>
>>>>>>>>>>> + <dependency>
>>>>>>>>>>> + <groupId>org.jogamp.gluegen</groupId>
>>>>>>>>>>> + <artifactId>gluegen-rt-main</artifactId>
>>>>>>>>>>> + <version>2.0.2</version>
>>>>>>>>>>> + </dependency>
>>>>>>>>>>>
>>>>>>>>>>> Hope that could help you,
>>>>>>>>>>>
>>>>>>>>>>> Seb
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 9, 2013 at 7:22 AM, Marco Sambin <m.sambin at gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Dear VTKers,
>>>>>>>>>>>>
>>>>>>>>>>>> I am developing a VTK 6-based Java application, and I am making
>>>>>>>>>>>> some efforts to make it compatible with Mac OS X as well.
>>>>>>>>>>>>
>>>>>>>>>>>> I know that the jawt embedding currently supported by Java 7 on
>>>>>>>>>>>> Mac (which is CALayer-based) does not work with VTK 6 (nor with previous
>>>>>>>>>>>> VTK versions), but there are several portions of my application which do
>>>>>>>>>>>> not use direct drawing by VTK classes to Java panels (i.e., do not use
>>>>>>>>>>>> jawt), hence will work fine on Mac + Java 7 as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Now, for the portions of my application where VTK classes need
>>>>>>>>>>>> to actually "draw", my question is: will offscreen rendering work on Mac?
>>>>>>>>>>>> The basic idea would be to grab the output of the offscreen rendering,
>>>>>>>>>>>> convert it to a Java-compatible image, and draw it to a Java panel. I know
>>>>>>>>>>>> this will be a significant performance penalty, but my requirements in this
>>>>>>>>>>>> moment are not so strict or demanding under this point of view.
>>>>>>>>>>>>
>>>>>>>>>>>> In particular, I have a vtkCanvas-derived panel, where I
>>>>>>>>>>>> display some planes in 3D (actually, they are vtkImagePlaneWidgets, but I
>>>>>>>>>>>> am mainly interested in the "display" functionality, not in the
>>>>>>>>>>>> interactivity of the widget with the user). Will it be sufficient to call
>>>>>>>>>>>> myVtkCanvas.GetRenderWindow().SetOffScreenRendering(1) to obtain offscreen
>>>>>>>>>>>> rendering on my Mac? Or it is more complicated than that?
>>>>>>>>>>>>
>>>>>>>>>>>> Currently, calling just
>>>>>>>>>>>> myVtkCanvas.GetRenderWindow().SetOffScreenRendering(1), I am obtaining a
>>>>>>>>>>>> crash in the OpenGL library when running my application on the Mac.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks in advance for your feedback.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Marco
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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/20130913/97ac0b34/attachment.htm>
More information about the vtkusers
mailing list