[vtkusers] VTK6 + Java7 on Mac: offscreen rendering?
Sebastien Jourdain
sebastien.jourdain at kitware.com
Thu Sep 12 10:11:21 EDT 2013
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/20130912/3c775835/attachment.htm>
More information about the vtkusers
mailing list