Notes |
|
(0031030)
|
Dave DeMarle
|
2013-06-24 19:54
|
|
|
|
(0031035)
|
Michka Popoff
|
2013-06-25 01:52
|
|
Yes I can do this, let me one or two days, I'll make a patch.
|
|
|
(0031077)
|
Michka Popoff
|
2013-06-25 17:24
|
|
|
|
(0031086)
|
Clinton Stimpson
|
2013-06-26 12:09
|
|
X11 errors come from not having a correct X window for rendering. QVTKWidget.cpp gets around this by having some X11 specific code.
By using QGLWidget, you now have 2 full buffers allocated for rendering. So you are eating up more memory.
If painting requests come through QGLWidget, it does the following:
1. Makes the QGLWidget context current
2. calls vtkRenderWindow Render()
2a. Makes the vtkRenderWindow contect current and does rendering
2b. swaps the buffers
3. QGLWidget swaps the current buffers again (in this case it swaps the VTK buffer, not the QGLWidget one).
Its incorrect to swap the buffer 2 times. The 2nd one will put an old image back on screen.
I just think you are switching out one set of bugs for another set of bugs. Some ideas for fixing this:
1. Follow the QVTKWidget2 pattern
2. Use python wrappers for C++ QVTKWidget/QVTKWidget2
3. Add additional python code to call Xlib to fix the X errors. |
|
|
(0031105)
|
Michka Popoff
|
2013-06-29 17:34
|
|
Thank you for the help, I understand why my solution is a "bad" solution. So I think we can close the patch on gerrit.
I was able to compile VTK to get QVTKWidget, and was able to embed it in my PyQT app. So the problem is solved for me.
The solution 3) seems easy to use, I had no time to test it but if the only thing to do is to add Xlib imports, it should be OK.
Perhaps there should be some documentation about this stuff ? I found no "official" documentation of QVTKWidget / QVTKWidget2 in the classes list (http://www.vtk.org/doc/release/5.10/html/ [^]) or in the Wiki.
For beginners, there should perhaps be a Wiki entry, which would explain the differences between QVTKRenderWindowInteractor, QVTKWidget and QVTKWidget2. Reading the tips and tricks on internet is quite confusing, the discussions are outdated or not accurate (like the fix I proposed and some people are using ...).
Besides, I use QVTKWidget, because QVTKWidget2 was not wrapped and can not be found (I don't know why ...). Perhaps it's only available since 6.0.0 ? |
|
|
(0031110)
|
Clinton Stimpson
|
2013-07-01 12:47
|
|
I can imagine documentation being like that.
It started a while back with QVTKWidget and QVTKRenderWindowInteractor being independent implementations. QVTKWidget was used with C++ and QVTKRenderWindowInteractor with python. Over time, QVTKWidget2 was added which was based of QGLWidget, and python wrappings were added later. The python wrappings cover several classes, and not just QVTKWidget*. QVTKWidget2 can be wrapped in python if you also enable the flag VTK_USE_QVTK_QTOPENGL:BOOL=ON. I may be wrong, as I haven't built VTK in quite some time, and I haven't used VTK 6.0. I'm not aware of any good documentation that has been kept up to date over the time.
Anyway, I would recommend #1 or #2 over #3. Using QGLWidget properly gives a bunch more cool functionality. Some of that can be demonstrated in the qtgraphicsview example. |
|
|
(0031112)
|
Michka Popoff
|
2013-07-01 16:15
|
|
Okay, I added VTK_USE_QVTK_QTOPENGL:BOOL=ON, now I also have the QVTKWidget2 in python.
The explanations you gave should definitively be written down in the wiki, this is very helpful. It would help people chose the Widget they want to use, and which option to turn On/Off in cmake.
I am closing this ticket, my patch in gerrit can also be closed.
Thank you very much for your help. |
|