ParaView/Developer Info: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
 
(12 intermediate revisions by 4 users not shown)
Line 5: Line 5:
=== From Fbertel Wiki Page ===
=== From Fbertel Wiki Page ===


==== VTK Rendering Contextbehavior to keep in mind ====
==== VTK Rendering Context behavior to keep in mind ====


Switching from onscreen to offscreen rendering can change the OpenGL context of the same renderwindow. Those OpenGL context can have different extensions support. For instance, on Windows, the onscreen can use the GPU but the offscreen may use the GDI OpenGL 1.1. It is really nasty in term of tracking available extensions: any class using extensions and caching a flag about the success of extension
Switching from onscreen to offscreen rendering can change the OpenGL context of the same renderwindow. Those OpenGL context can have different extensions support. For instance, on Windows, the onscreen can use the GPU but the offscreen may use the GDI OpenGL 1.1. It is really nasty in term of tracking available extensions: any class using extensions and caching a flag about the success of extension
Line 11: Line 11:
list of static global pointers... on top of that they are not reset or swap between context switches.
list of static global pointers... on top of that they are not reset or swap between context switches.


==== VTK and RenderWindow ====
==== OpenGL Extension Manager ====


If you want to render the same scene, from different point of view (ie camera) in different windows, you cannot share the scene (for example, the actors) between windows because concrete props have rendering OpenGL code and potentially associated OpenGL resources (like texture object Id or display list Id). Typical application is the same scene, rendered in perspective in one window and
The OpenGL extension manager calls Render() on the render window to make sure a OpenGL context is created. Basically, it calls a function <b>only for its the side effect</b>. In the first place a function should not have side effects. The OpenGL extension manager should call a function that create the OpenGL context directly. Currently, it causes egg and chicken issues when vtkOpenGLRenderWindow::OpenGLinit calls the openGL extension manager.
renderered in orthoview in 3 other windows oriented along X,Y and Z.


Right now, the only solutions (... I Can think of) is to duplicate everything in each renderwindow (more exactly in each vtkRenderer) and to have some logic to keep duplicated data in sync... Or
to switch the associated system window each time you render something but it implies releasing the OpenGL resources each time you switch between windows.
A real solution should be to re-architecture VTK to make a scene as a DAG where every object just contains information, not rendering code. Rendering code should be in a visitor. The visitor
should keep handle on OpenGL resources (it can also be a text visitor to dump info into a file, or scene writer  to save the objects, or a picker visitor, or a renderman visitor, or a direct3D visitor...).
What will happen to the mappers, then? What would happen to the volume mappers?
==== Bad code in the OpenGL extension manager ====
the OpenGL extension manager calls Render() on the render window to make sure a OpenGL context is created. Basically, it calls a function <b>only for its the side effect</b>. In the first place a function should not have side effects. The OpenGL extension manager should call a function that create the OpenGL context directly. Currently, it causes egg and chicken issues when vtkOpenGLRenderWindow::OpenGLinit calls the openGL extension manager.
==== Regression test images and Windows ====
On Windows, the width of windows cannot be smaller than the width of the decoration (close button, etc..). This is 103 on Windows XP and 107 on Windows Vista and may vary with preferences (accessibility or style profile,...). If a vtkRenderWindow is request to have 100 width, the system will make it 103 or 107 and the test will fail because the test image and valid image width don't match. Conclusion: tests have to have images wider than 107.


== Server Manager Development ==
== Server Manager Development ==
Line 46: Line 30:


Both methods support the QEventLoop::ProcessEventsFlags flags argument. For more information on processEvents please see the [http://doc.qt.nokia.com/4.7/qcoreapplication.html#processEvents Qt Documentation]
Both methods support the QEventLoop::ProcessEventsFlags flags argument. For more information on processEvents please see the [http://doc.qt.nokia.com/4.7/qcoreapplication.html#processEvents Qt Documentation]
== Testing ==
=== Pause Event ===
To add a pause to a ParaView XML test:
<pqevent object="<MainWindow>" command="pause" arguments="<msec>" />


== Debugging ==
== Debugging ==


===DebugLeaksView===
A great way to track down VTK classes that are leaking is using [[DebugLeaksView]]. The widget is designed to work out of the box with any VTK+Qt application- just construct the widget and call show(). More information can be found on the [[DebugLeaksView]] page. The vtk code is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/VTK.git and
A great way to track down VTK classes that are leaking is using [[DebugLeaksView]]. The widget is designed to work out of the box with any VTK+Qt application- just construct the widget and call show(). More information can be found on the [[DebugLeaksView]] page. The vtk code is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/VTK.git and
the code to embed the widget into paraview is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/ParaView.git
the code to embed the widget into paraview is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/ParaView.git
Line 54: Line 46:
[[Image:Debug_leaks_widget_1.png|center|thumb|500px]]
[[Image:Debug_leaks_widget_1.png|center|thumb|500px]]


== Environment Flags ==
===PARAVIEW_DATA_ROOT===
Change the location of the data root for testing.


=== PV_DEBUG_TEST ===
=== OpenGL Debugging Tool ===
Prints debugging information about the testing framework during playback to cout.
[http://zrusin.blogspot.com/2011/04/apitrace.html ApiTrace] is a project to trace, analyze and debug graphics api's. Both OpenGL and Direct3D. To some extend inspired by gDEBugger and Windows PIX. We wanted a tool that would let us slice through huge games and CAD apps to the exact call which causes problems and be able to inspect the entire graphics state, including the shaders, textures and all the buffers.  [http://zrusin.blogspot.com/2011/04/apitrace.html See here for more info]


===PV_ICET_WINDOW_BORDERS===
=== Windows Console Debug Output ===
Force render windows to be 400x400 instead of fullscreen
To Enable printing of cout and printf during debugging Change the linking properties of the paraview target by right clicking it and selecting properties. In the Property pages drill down through: Configuration Properties -> Linker -> System -> SubSystem. Change Windows(/SUBSYSTEM:WINDOWS) to Console(/SUBSYSTEM:CONSOLE). Build the paraview target. Now when you run ParaView a console Window will also spawn where all your standard output will be printed. Note: Unfortunately if CMake is re-run this property will be reset.


===PV_NO_OFFSCREEN_SCREENSHOTS===
== Environment Flags ==
Disable the use of offsceen screenshots
 
===PV_PLUGIN_DEBUG===
Prints debugging information when loading plugins into ParaView.
 
===PV_PLUGIN_PATH===
Directories containing plugins to be loaded on startup
 
===PV_SOFTWARE_RENDERING===
Force software rendering for ParaView.
 
===PV_LOCK_SAFE===
Disables the use of the vtkTransmit<Type>Piece classes and instead uses vtkExtract<Type>Piece


===QT_MAC_NO_NATIVE_MENUBAR===
These have been moved to the [http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/EnvironmentVariables.html ParaView Doxygen] generated pages.
Qt flag to force the Qt menu bar rather than the native mac menu bar.

Latest revision as of 16:20, 16 December 2015

This is a general collection of knowledge to help make developing for ParaView easier.

VTK Development

From Fbertel Wiki Page

VTK Rendering Context behavior to keep in mind

Switching from onscreen to offscreen rendering can change the OpenGL context of the same renderwindow. Those OpenGL context can have different extensions support. For instance, on Windows, the onscreen can use the GPU but the offscreen may use the GDI OpenGL 1.1. It is really nasty in term of tracking available extensions: any class using extensions and caching a flag about the success of extension loading should keep track of the OpenGL context where the function pointers were initialized. It also means that the function pointers (vtkgl::) should be per context, right now it is a list of static global pointers... on top of that they are not reset or swap between context switches.

OpenGL Extension Manager

The OpenGL extension manager calls Render() on the render window to make sure a OpenGL context is created. Basically, it calls a function only for its the side effect. In the first place a function should not have side effects. The OpenGL extension manager should call a function that create the OpenGL context directly. Currently, it causes egg and chicken issues when vtkOpenGLRenderWindow::OpenGLinit calls the openGL extension manager.


Server Manager Development

XML Hints

http://www.paraview.org/Wiki/ServerManager_XML_Hints

Qt Development

QApplication::processEvents()

Because of the testing framework we are unable to safely use processEvents. The testing framework has a busy lock it uses to determine when it should play the next testing event. If that busy lock is running when your code calls processEvents it will cause the tests to start playing, which will break the test. The solution is dependent on where you need to call processEvents. 

 pqCoreUtilities::processEvents();
 pqEventDispatcher::processEvents(); //only in Widgets since widgets can't depend on core

Both methods support the QEventLoop::ProcessEventsFlags flags argument. For more information on processEvents please see the Qt Documentation

Testing

Pause Event

To add a pause to a ParaView XML test: 

<pqevent object="<MainWindow>" command="pause" arguments="<msec>" />

Debugging

DebugLeaksView

A great way to track down VTK classes that are leaking is using DebugLeaksView. The widget is designed to work out of the box with any VTK+Qt application- just construct the widget and call show(). More information can be found on the DebugLeaksView page. The vtk code is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/VTK.git and the code to embed the widget into paraview is available in the qt-vtk-debug-leaks-view branch of git://github.com/patmarion/ParaView.git

Debug leaks widget 1.png


OpenGL Debugging Tool

ApiTrace is a project to trace, analyze and debug graphics api's. Both OpenGL and Direct3D. To some extend inspired by gDEBugger and Windows PIX. We wanted a tool that would let us slice through huge games and CAD apps to the exact call which causes problems and be able to inspect the entire graphics state, including the shaders, textures and all the buffers. See here for more info

Windows Console Debug Output

To Enable printing of cout and printf during debugging Change the linking properties of the paraview target by right clicking it and selecting properties. In the Property pages drill down through: Configuration Properties -> Linker -> System -> SubSystem. Change Windows(/SUBSYSTEM:WINDOWS) to Console(/SUBSYSTEM:CONSOLE). Build the paraview target. Now when you run ParaView a console Window will also spawn where all your standard output will be printed. Note: Unfortunately if CMake is re-run this property will be reset.

Environment Flags

These have been moved to the ParaView Doxygen generated pages.

Retrieved from "https://public.kitware.com/Wiki/index.php?title=ParaView/Developer_Info&oldid=58609"