<p dir="ltr">Hi Seb,</p>
<p dir="ltr">The following test case was crashing for me on my Linux test machine: I had three vtkImagePlaneWidgets displayed on a vtkPanel/vtkCanvas panel. Then, I programmatically called SetWindowLevel() on the three widgets: this caused the application to crash. If it is relevant, the call to SetWindowLevel was done directly from the EDT.<br>
The crash disappeared once I subclassed vtkImagePlaneWidget, removed the Interactor->Render() call at the end of the SetWindowLevel() method, and issued the Render() from Java code.</p>
<p dir="ltr">This crash was happening only on Linux for me. Working fine on Windows.</p>
<p dir="ltr">Regards,</p>
<p dir="ltr">Marco<br><br></p>
<p dir="ltr">Il giorno 24/set/2013 02:10, "Sebastien Jourdain" <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> ha scritto:<br>
><br>
> Hi Marco,<br>
><br>
> the fix is only fully valid for the vtkGenericOpenGLRenderWindow which is not the one used inside the vtkCanvas and vtkPanel.<br>
> Moreover, I never encounter that issue with vtkCanvas/vtkPanel. Do you have a use case that highlight that specific issue?<br>
> If so, then maybe you right that would be a good add on. And it could be added as a separate method which can be called by the user at initialization. (i.e.: panel.disableDirectCallToNativeRender())<br>
><br>
> And if you have ideas or improvement that you would like to contribute. Please do so on gerrit and add me as a reviewer.<br>
><br>
> Seb<br>
><br>
><br>
><br>
><br>
> On Mon, Sep 23, 2013 at 4:24 PM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>><br>
>> Hi Seb,<br>
>><br>
>> thanks for your reply.<br>
>><br>
>> Regarding point 2., yes, I saw the fix on GIT and it can easily be replicated in my user code without touching VTK code. But my question was in general about the opportunity to apply the same patch to vtkCanvas/vtkPanel's out-of-the-box implementation, in such a way users should not need to apply fixes in their user code. What do you think about this? Do you think this patch would be valid in general, or rather you think there are good reasons to keep vtkCanvas/vtkPanel's stock implementation as it is now?<br>
>><br>
>> Regarding point 1., if I'll discover something useful, I will share it on this list.<br>
>><br>
>> Thanks for your comments, as always.<br>
>><br>
>> Regards,<br>
>><br>
>> Marco<br>
>><br>
>> Il giorno 21/set/2013 22:45, "Sebastien Jourdain" <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> ha scritto:<br>
>><br>
>>> Hi Marco,<br>
>>><br>
>>><br>
>>> For 1, I don't think so. It may be related to the fact that the GLContext get re-created and messed things up. We've noticed something similar while tracking the issue 2. But as we didn't had a good understanding on how to handle it properly, we just skip it for now. But any further investigation from the community is welcome. We noticed it when we moved the view from one desktop to another on Linux.<br>
>>> <br>
>>> For 2, you don't really need to change the code, you can do it within your code by calling those method appropriately.<br>
>>><br>
>>> canvas.GetInteractor().AddObserver("RenderEvent", canvas, "repaint");<br>
>>> canvas.GetInteractor().SetEnableRender(false);<br>
>>><br>
>>> Hope that helps,<br>
>>><br>
>>> Seb<br>
>>><br>
>>><br>
>>> On Sat, Sep 21, 2013 at 2:34 AM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Thanks a lot Seb!<br>
>>>><br>
>>>> I was really glad to help, and I will do it again in the future if I'll have a chance.<br>
>>>> I will test the fix soon.<br>
>>>><br>
>>>> A couple of questions:<br>
>>>><br>
>>>> 1) Will the fix have some influence on the issues I described in my other recent post to the list, titled "Issues with vtkJoglCanvasComponent/vtkJoglPanelComponent"?<br>
>>>><br>
>>>> 2) Don't you think the same fix shall be extended to vtkCanvas/vtkPanel as well? Especially on Linux, even with these components I experienced crashes on Interactor->Render() calls from native code, exactly as with JOGL components. My workaround was i fact the same as with JOGL.<br>
>>>><br>
>>>> Thanks in advance for your comments and feedback, I really appreciate the responsiveness of you guys and of this list in general!<br>
>>>><br>
>>>> Regards,<br>
>>>><br>
>>>> Marco<br>
>>>><br>
>>>> Il giorno 21/set/2013 04:42, "Sebastien Jourdain" <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> ha scritto:<br>
>>>><br>
>>>>> FYI the fix can be seen here: <a href="http://review.source.kitware.com/#/t/3294/">http://review.source.kitware.com/#/t/3294/</a><br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Sep 20, 2013 at 10:41 PM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Hi Marco, <br>
>>>>>><br>
>>>>>> I've just push a fix to the git repo.<br>
>>>>>> Thank you again for your investigation.<br>
>>>>>> Your help was much appreciated.<br>
>>>>>><br>
>>>>>> Seb<br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, Sep 13, 2013 at 11:01 AM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> Thanks Marco,<br>
>>>>>>><br>
>>>>>>> This is awesome!<br>
>>>>>>> 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.<br>
>>>>>>> But your investigation is very valuable.<br>
>>>>>>><br>
>>>>>>> Thanks again,<br>
>>>>>>><br>
>>>>>>> Seb<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Fri, Sep 13, 2013 at 10:22 AM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> Hi all,<br>
>>>>>>>><br>
>>>>>>>> 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 ;-)):<br>
>>>>>>>><br>
>>>>>>>> 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.<br>
>>>>>>>> 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).<br>
>>>>>>>><br>
>>>>>>>> 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.<br>
>>>>>>>> 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.<br>
>>>>>>>><br>
>>>>>>>> 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!<br>
>>>>>>>><br>
>>>>>>>> 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.<br>
>>>>>>>><br>
>>>>>>>> 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).<br>
>>>>>>>><br>
>>>>>>>> Comments are appreciated.<br>
>>>>>>>><br>
>>>>>>>> Thanks in advance and best regards,<br>
>>>>>>>><br>
>>>>>>>> Marco Sambin<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On Thu, Sep 12, 2013 at 4:11 PM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Hi Marco,<br>
>>>>>>>>><br>
>>>>>>>>> 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.<br>
>>>>>>>>><br>
>>>>>>>>> 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.<br>
>>>>>>>>><br>
>>>>>>>>> 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.<br>
>>>>>>>>><br>
>>>>>>>>> Seb<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On Thu, Sep 12, 2013 at 2:24 AM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> Ok Seb,<br>
>>>>>>>>>><br>
>>>>>>>>>> I understand, and thank you for your feedback.<br>
>>>>>>>>>> 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.<br>
>>>>>>>>>><br>
>>>>>>>>>> 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?<br>
>>>>>>>>>><br>
>>>>>>>>>> Thanks and best regards,<br>
>>>>>>>>>><br>
>>>>>>>>>> Marco<br>
>>>>>>>>>><br>
>>>>>>>>>> Il giorno 11/set/2013 18:44, "Sebastien Jourdain" <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> ha scritto:<br>
>>>>>>>>>><br>
>>>>>>>>>>> Hum,<br>
>>>>>>>>>>><br>
>>>>>>>>>>> thanks Marco for your help but it seems to be a tricky bug...<br>
>>>>>>>>>>> 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.<br>
>>>>>>>>>>> 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.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Thanks again,<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Seb<br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> On Wed, Sep 11, 2013 at 12:22 PM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Hi all,<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Here is the crash dump I obtained on Linux, which is maybe even more useful than the previous one:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> ===================<br>
>>>>>>>>>>>> [...]<br>
>>>>>>>>>>>> Stack: [0x00007fcecd37e000,0x00007fcecd47f000], sp=0x00007fcecd47b6e0, free space=1013k<br>
>>>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)<br>
>>>>>>>>>>>> C [<a href="http://libvtkRenderingOpenGL-6.1.so">libvtkRenderingOpenGL-6.1.so</a>+0x113817] vtkUpload3D<unsigned char>::Upload(void*, unsigned char*, unsigned int*, int, long long*, int, int*)+0x69<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)<br>
>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0<br>
>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1<br>
>>>>>>>>>>>> j vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227<br>
>>>>>>>>>>>> j java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54<br>
>>>>>>>>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81<br>
>>>>>>>>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581<br>
>>>>>>>>>>>> j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2<br>
>>>>>>>>>>>> j java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V+41<br>
>>>>>>>>>>>> j java.awt.EventQueue.access$200(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V+3<br>
>>>>>>>>>>>> j java.awt.EventQueue$3.run()Ljava/lang/Void;+12<br>
>>>>>>>>>>>> j java.awt.EventQueue$3.run()Ljava/lang/Object;+1<br>
>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>> J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>> j java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+28<br>
>>>>>>>>>>>> j java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+6<br>
>>>>>>>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Void;+11<br>
>>>>>>>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Object;+1<br>
>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>> J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>> J java.awt.EventDispatchThread.pumpOneEventForFilters(I)V<br>
>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35<br>
>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11<br>
>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4<br>
>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3<br>
>>>>>>>>>>>> j java.awt.EventDispatchThread.run()V+9<br>
>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> [...]<br>
>>>>>>>>>>>> ===================<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I am looking forward to hearing your comments.<br>
>>>>>>>>>>>> Thanks in advance and best regards,<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Marco Sambin<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> On Wed, Sep 11, 2013 at 4:34 PM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Hi Seb,<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> thanks for your feedback.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> I've just tested on Mac (Mac OS X 10.8.4, Java 7u25, Macbook Pro i5), and here is what happens:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> - 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! :-)).<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> - 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.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> - 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:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> =================<br>
>>>>>>>>>>>>> [...]<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Stack: [0x000000013d09c000,0x000000013d19c000], sp=0x000000013d197fa0, free space=1007k<br>
>>>>>>>>>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)<br>
>>>>>>>>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x857b7] _ZN11vtkUpload3DIhE6UploadEPvPhPjiPxiPi+0xd5<br>
>>>>>>>>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x81834] _ZN20vtkPixelBufferObject8Upload3DEiPvPjiPxiPi+0x9a8<br>
>>>>>>>>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x7a085] _ZN16vtkOpenGLTexture4LoadEP11vtkRenderer+0x1a7d<br>
>>>>>>>>>>>>> C [libvtkRenderingFreeType-6.1.1.dylib+0x1b8c6] _ZN12vtkTextActor13RenderOverlayEP11vtkViewport+0x5a<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7bd38] _ZN11vtkRenderer14UpdateGeometryEv+0x114<br>
>>>>>>>>>>>>> C [libvtkRenderingOpenGL-6.1.1.dylib+0x6a3aa] _ZN17vtkOpenGLRenderer12DeviceRenderEv+0xea<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7b5c1] _ZN11vtkRenderer6RenderEv+0x26f<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x7aacc] _ZN21vtkRendererCollection6RenderEv+0x5a<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x824c3] _ZN15vtkRenderWindow14DoStereoRenderEv+0x83<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x8241b] _ZN15vtkRenderWindow10DoFDRenderEv+0x38d<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x8206a] _ZN15vtkRenderWindow10DoAARenderEv+0x43a<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x81905] _ZN15vtkRenderWindow6RenderEv+0x149<br>
>>>>>>>>>>>>> C [libvtkRenderingCore-6.1.1.dylib+0x85673] _ZN25vtkRenderWindowInteractor6RenderEv+0x27<br>
>>>>>>>>>>>>> C [libvtkCommonCore-6.1.1.dylib+0x59561] _ZN18vtkCallbackCommand7ExecuteEP9vtkObjectmPv+0x21<br>
>>>>>>>>>>>>> C [libvtkCommonCore-6.1.1.dylib+0xb60bc] _ZN16vtkSubjectHelper11InvokeEventEmPvP9vtkObject+0x39a<br>
>>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0<br>
>>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1<br>
>>>>>>>>>>>>> j vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227<br>
>>>>>>>>>>>>> j java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54<br>
>>>>>>>>>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81<br>
>>>>>>>>>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)<br>
>>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent_109()V+0<br>
>>>>>>>>>>>>> j vtk.vtkRenderWindowInteractor.LeftButtonPressEvent()V+1<br>
>>>>>>>>>>>>> j vtk.rendering.vtkInteractorForwarder.mousePressed(Ljava/awt/event/MouseEvent;)V+227<br>
>>>>>>>>>>>>> j java.awt.Component.processMouseEvent(Ljava/awt/event/MouseEvent;)V+54<br>
>>>>>>>>>>>>> j java.awt.Component.processEvent(Ljava/awt/AWTEvent;)V+81<br>
>>>>>>>>>>>>> j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+581<br>
>>>>>>>>>>>>> J java.awt.EventQueue.access$200(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V<br>
>>>>>>>>>>>>> J java.awt.EventQueue$3.run()Ljava/lang/Object;<br>
>>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>>> J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>>> J java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>>> j java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+6<br>
>>>>>>>>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Void;+11<br>
>>>>>>>>>>>>> j java.awt.EventQueue$4.run()Ljava/lang/Object;+1<br>
>>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>>> J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>>> J java.security.ProtectionDomain$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;<br>
>>>>>>>>>>>>> j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+73<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpOneEventForFilters(I)V+245<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3<br>
>>>>>>>>>>>>> j java.awt.EventDispatchThread.run()V+9<br>
>>>>>>>>>>>>> v ~StubRoutines::call_stub<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> [...]<br>
>>>>>>>>>>>>> =================<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Please let me know if this tells you something useful, and if I can be of further help.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> I will now make some tests on Linux as well, and will report back to you.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Thanks and best regards,<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Marco Sambin<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> On Wed, Sep 11, 2013 at 6:10 AM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> Hi Marco,<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> 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).<br>
>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> Do you mind testing that on Mac and letting me know if the issue exist?<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> Seb<br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>> On Tue, Sep 10, 2013 at 1:06 PM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> Hi Seb,<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> thanks for your feedback.<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> 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%.<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> Can you guess what is causing this behavior? Is interaction with widgets supposed to work when using JOGL?<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> 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)?<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> Thanks again for your feedback: this path seems really promising, and may open a whole new world with using VTK from Java.<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> Regards,<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> Marco<br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>> On Mon, Sep 9, 2013 at 5:33 PM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>> Hi Marco, <br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>> you will have to use another class. But you will have the same integration capability.<br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>> Look at src/VTK/Wrapping/Java/vtk/sample/rendering/JoglConeRendering.java for more details.<br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>> Seb<br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>> On Mon, Sep 9, 2013 at 10:37 AM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>> Hi Seb,<br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>> this is great news, and I will give it a try!<br>
>>>>>>>>>>>>>>>>> One question: will I be able to keep using vtkCanvas as a Java panel class, or rather shall I move to something different?<br>
>>>>>>>>>>>>>>>>> Thanks again for your feedback.<br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>> Best regards,<br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>> Marco Sambin<br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>> On Mon, Sep 9, 2013 at 2:45 PM, Sebastien Jourdain <<a href="mailto:sebastien.jourdain@kitware.com">sebastien.jourdain@kitware.com</a>> wrote:<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> Hi Marco,<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> you won't be able to rely on offscreen rendering on Mac to properly handle the issue you are trying to overcome.<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> 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).<br>
>>>>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>>>>> Otherwise you will need to specify their paths.<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> Here is the dependency for Maven.<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> + <dependency><br>
>>>>>>>>>>>>>>>>>> + <groupId>org.jogamp.jogl</groupId><br>
>>>>>>>>>>>>>>>>>> + <artifactId>jogl-all-main</artifactId><br>
>>>>>>>>>>>>>>>>>> + <version>2.0.2</version><br>
>>>>>>>>>>>>>>>>>> + </dependency><br>
>>>>>>>>>>>>>>>>>> + <dependency><br>
>>>>>>>>>>>>>>>>>> + <groupId>org.jogamp.gluegen</groupId><br>
>>>>>>>>>>>>>>>>>> + <artifactId>gluegen-rt-main</artifactId><br>
>>>>>>>>>>>>>>>>>> + <version>2.0.2</version><br>
>>>>>>>>>>>>>>>>>> + </dependency><br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> Hope that could help you,<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> Seb<br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>> On Mon, Sep 9, 2013 at 7:22 AM, Marco Sambin <<a href="mailto:m.sambin@gmail.com">m.sambin@gmail.com</a>> wrote:<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Dear VTKers,<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> 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.<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> 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?<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Currently, calling just myVtkCanvas.GetRenderWindow().SetOffScreenRendering(1), I am obtaining a crash in the OpenGL library when running my application on the Mac.<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Thanks in advance for your feedback.<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Best regards,<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Marco<br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>>>>>>>>> Powered by <a href="http://www.kitware.com">www.kitware.com</a><br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:<br>
>>>>>>>>>>>>>>>>>>> <a href="http://www.vtk.org/mailman/listinfo/vtkusers">http://www.vtk.org/mailman/listinfo/vtkusers</a><br>
>>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>>><br>
>>>>>>>>>>>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>><br>
>>>>><br>
>>><br>
><br>
</p>