API Changes between ParaView versions¶
Changes in 5.10¶
Render View Background Color¶
UseGradientBackground, UseTexturedBackground and UseSkyboxBackground properties have been replaced by BackgroundColorMode which is an enumeration which lets user choose how to render the background. Supported values are “Single Color”, “Gradient”, “Texture” and “Skybox”.
Additionally, a new boolean property UseColorPaletteForBackground is now available. Unless this property is set to 0, the view will ignore background color overrides specified on the view and instead use the global color palette.
Changes in 5.7¶
Views and Layouts¶
CreateView, CreateRenderView, etc. no longer automatically associates the created view with a layout. One has to explicitly assign the view to a layout. simple.AssignViewToLayout may be used to assign the view to an available layout, or create a new one if none exists.
detachedFromLayout argument to all the view creation functions is now obsolete since all views are created detached from layout.
Changes in 5.5¶
SaveScreenshot and SaveAnimation parameters¶
ImageQuality keyword parameter has been deprecated and will be ignored. Instead, users are expected to provide format spefic keyword parameters that control output quality. This allows for a fine grained control over the output quality based on the file format, rather than hiding it under a single quality number.
Offscreen rendering¶
ParaView executables now automatically choose to use offscreen rendering, if appropriate. For Python executables, pvbatch automatically uses offscreen by default (even headless i.e. using EGL or OSMesa if built with support for the same), and pvpython opts for onscreen. You can override the same by passing command line arguments –force-offscreen-rendering or –force-onscreen-rendering.
As a result view.UseOffscreenRendering property has been removed to avoid conflicting with this automatic logic.
Likewise, view.UseOffscreenRenderingForScreenshots has been removed too. That option is no longer needed as ParaView is no longer affected by overlapping windows when capturing screenshots.
Changes in 5.1¶
Cube Axes no longer available¶
Cube axes is no longer supported by ParaView. Hence all calls to display
properties for the same should now be simply removed from your Python code. e.g.
display.CubeAxesVisibility = .. and other such properties that began with
CubeAxes are no longer available and should be removed.
A complete list of display properties removed is as follows:
CubeAxesVisibility,
CubeAxesColor, CubeAxesCornerOffset, CubeAxesFlyMode,
CubeAxesInertia, CubeAxesTickLocation,
CubeAxesXAxisMinorTickVisibility, CubeAxesXAxisTickVisibility,
CubeAxesXAxisVisibility, CubeAxesXGridLines, CubeAxesXTitle,
CubeAxesUseDefaultXTitle, CubeAxesYAxisMinorTickVisibility,
CubeAxesYAxisTickVisibility, CubeAxesYAxisVisibility,
CubeAxesYGridLines, CubeAxesYTitle, CubeAxesUseDefaultYTitle,
CubeAxesZAxisMinorTickVisibility, CubeAxesZAxisTickVisibility,
CubeAxesZAxisVisibility, CubeAxesZGridLines, CubeAxesZTitle,
CubeAxesUseDefaultZTitle, CubeAxesGridLineLocation, DataBounds,
CustomBounds, CustomBoundsActive, OriginalBoundsRangeActive,
CustomRange, CustomRangeActive, UseAxesOrigin, AxesOrigin,
CubeAxesXLabelFormat, CubeAxesYLabelFormat, CubeAxesZLabelFormat,
StickyAxes, CenterStickyAxes.
CameraClippingRange on render view¶
For a few releases, CameraClippingRange property would not have any effect on a render view.
Since the clipping range is now managed by the vtkPVRenderView automatically, the user is not expected
to set this property any more. This release finally removes this property. To fix any existing Python scripts,
simply remove any code view.CameraClippingRange = ... from your script.
Changes in 4.2¶
Changes to defaults¶
This version includes major overhaul of the ParaView’s Python internals towards one main goal: making the results consistent between ParaView UI and Python applications e.g. when you create a RenderView, the defaults are setup consistently irrespective of which interface you are using. Thus, scripts generated from ParaView’s trace which don’t describe all property values may produce different results from previous versions.
Choosing data array for scalar coloring¶
In previous versions, the recommended method for selecting an array to color with was as follows:
disp = GetDisplayProperties(...)
disp.ColorArrayName = ("POINT_DATA", "Pressure")
# OR
disp.ColorArrayName = ("CELL_DATA", "Pressure")
However, scripts generated from ParaView’s trace, would result in the following:
disp.ColorArrayName = "Pressure"
disp.ColorAttributeType = "POINT_DATA"
The latter is no longer supported i.e. ColorAttributeType property is no
longer available. You uses ColorArrayName to specify both the array
association and the array name, similar to the API for selecting arrays on
filters. Additionally, the attribute type strings POINT_DATA and
CELL_DATA while still supported are deprecated. For consistency, you use
POINTS, CELLS, etc. instead.
disp.ColorArrayName = ("POINTS", "Pressure")
Chart properties¶
There are three types of changes to APIs that set chart properties.
1. Axis properties were set using arrays that contain elements for all axes (left, bottom, right and top). Now these settings are separated such that each axis has its own function. There are three groups of properties affected.
Color settings used arrays of 12 elements to set the color for all axes. In the current version we use a function for each axis, each with 3 elements.
AxisColorAxisGridColorAxisLabelColorAxisTitleColor
Font properties used arrays of 16 elements, 4 elements for each
axis. In the current version we use a function for each axis and for
each font property. See the also the section on font properties.
a. AxisLabelFont
b. AxisTitleFont
There are various other properties that used arrays of 4 elements, one element for each axis.
AxisLabelNotationAxisLabelPrecisionAxisLogScaleAxisTitleAxisUseCustomLabelsAxisUseCustomRangeShowAxisGridShowAxisLabels
The new function names are obtained by using prefixes Left, Bottom,
Right and Top before the old function names. For example, AxisColor
becomes LeftAxisColor, BottomAxisColor, RightAxisColor and
TopAxisColor.
2. Font properties were set using arrays of 4 elements. The 4 elements were font family, font size, bold and italic. In the current version we use a function for each font property. The functions affected are:
ChartTitleFontLeftAxisLabelFontBottomAxisLabelFontRightAxisLabelFontTopAxisLabelFontLeftAxisTitleFontBottomAxisTitleFontRightAxisTitleFontTopAxisTitleFont
The new function names can be obtained by replacing Font with FontFamily,
FontSize, Bold and Italic. So ChartTitleFont becomes
ChartTitleFontFamily, ChartTitleFontSize, ChartTitleBold,
ChartTitleItalic. Note that function names from bullet b to i are generated
in the previous step.
3. Range properties were set using an array of two elements. In the current version we use individual functions for the minimum and maximum element of the range. Properties affected are:
LeftAxisRangeBottomAxisRangeRightAxisRangeTopAxisRange
The new function names are obtained by using Minimum and Maximum
suffixes after the old function name. So LeftAxisRange becomes
LeftAxisRangeMinimum and LeftAxisRangeMaximum.
Glyph filters¶
The glyph filters (Glyph and GlyphWithCustomSource) have been refactored
in this release. This new filters offer new APIs for sampling and masking
points. The older implementation is still available. If you want to use the
older version of the filters instead, replace the constructor functions by
LegacyGlyph and LegacyArbitrarySourceGlyph respectively.
These older implementations, however, will be removed entirely in future releases. Hence, you should consider updating the script to use the newer version of this filter. If there is any functionality missing from the older implementation that you find useful, please use the mailing list to report to the developers.