[vtkusers] VTK6 + Java7 on Mac: offscreen rendering?
Marco Sambin
m.sambin at gmail.com
Tue Sep 24 02:17:01 EDT 2013
Hi Seb,
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.
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.
This crash was happening only on Linux for me. Working fine on Windows.
Regards,
Marco
Il giorno 24/set/2013 02:10, "Sebastien Jourdain" <
sebastien.jourdain at kitware.com> ha scritto:
>
> Hi Marco,
>
> the fix is only fully valid for the vtkGenericOpenGLRenderWindow which is
not the one used inside the vtkCanvas and vtkPanel.
> Moreover, I never encounter that issue with vtkCanvas/vtkPanel. Do you
have a use case that highlight that specific issue?
> 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())
>
> And if you have ideas or improvement that you would like to contribute.
Please do so on gerrit and add me as a reviewer.
>
> Seb
>
>
>
>
> On Mon, Sep 23, 2013 at 4:24 PM, Marco Sambin <m.sambin at gmail.com> wrote:
>>
>> Hi Seb,
>>
>> thanks for your reply.
>>
>> 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?
>>
>> Regarding point 1., if I'll discover something useful, I will share it
on this list.
>>
>> Thanks for your comments, as always.
>>
>> Regards,
>>
>> Marco
>>
>> Il giorno 21/set/2013 22:45, "Sebastien Jourdain" <
sebastien.jourdain at kitware.com> ha scritto:
>>
>>> Hi Marco,
>>>
>>>
>>> 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.
>>>
>>> For 2, you don't really need to change the code, you can do it within
your code by calling those method appropriately.
>>>
>>> canvas.GetInteractor().AddObserver("RenderEvent", canvas, "repaint");
>>> canvas.GetInteractor().SetEnableRender(false);
>>>
>>> Hope that helps,
>>>
>>> Seb
>>>
>>>
>>> On Sat, Sep 21, 2013 at 2:34 AM, Marco Sambin <m.sambin at gmail.com>
wrote:
>>>>
>>>> Thanks a lot Seb!
>>>>
>>>> I was really glad to help, and I will do it again in the future if
I'll have a chance.
>>>> I will test the fix soon.
>>>>
>>>> A couple of questions:
>>>>
>>>> 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"?
>>>>
>>>> 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.
>>>>
>>>> Thanks in advance for your comments and feedback, I really appreciate
the responsiveness of you guys and of this list in general!
>>>>
>>>> Regards,
>>>>
>>>> Marco
>>>>
>>>> Il giorno 21/set/2013 04:42, "Sebastien Jourdain" <
sebastien.jourdain at kitware.com> ha scritto:
>>>>
>>>>> FYI the fix can be seen here:
http://review.source.kitware.com/#/t/3294/
>>>>>
>>>>>
>>>>> On Fri, Sep 20, 2013 at 10:41 PM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
>>>>>>
>>>>>> Hi Marco,
>>>>>>
>>>>>> I've just push a fix to the git repo.
>>>>>> Thank you again for your investigation.
>>>>>> Your help was much appreciated.
>>>>>>
>>>>>> Seb
>>>>>>
>>>>>>
>>>>>> On Fri, Sep 13, 2013 at 11:01 AM, Sebastien Jourdain <
sebastien.jourdain at kitware.com> wrote:
>>>>>>>
>>>>>>> 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/20130924/4528720e/attachment.htm>
More information about the vtkusers
mailing list