[vtkusers] VTK6 + Java7 on Mac: offscreen rendering?
Marco Sambin
m.sambin at gmail.com
Fri Sep 13 10:22:46 EDT 2013
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/4fcdf8f3/attachment.htm>
More information about the vtkusers
mailing list