Skip to content

WIP: benchmark Kitware#65 on top of the CI/test branch - #2

Closed
user27182 wants to merge 7 commits into
masterfrom
perf/pr65-on-ci
Closed

user27182 wants to merge 7 commits into
masterfrom
perf/pr65-on-ci

Conversation

@user27182

Copy link
Copy Markdown
Owner

Test PR within this fork to compare CI benchmarks; not for upstream.

The changes of Kitware#65 (perf/rgbx-capture @ 9527216) cherry-picked onto the branch of fork PR #1 / Kitware#66 (fe54a08), so the benchmark can be compared with #1's run. The PR diff against master therefore includes #1's commits; the Kitware#65 changes are the last two commits.

Expected: the transposed-square layout tests fail, which is the known bug in Kitware#65's rgbx_view.

The Linux job installed Ubuntu's libturbojpeg 2.1.5, which lacks the tj3*
API that PyTurboJPEG 2 requires. PyTurboJPEG raised RuntimeError at import,
trame-rca fell back to Pillow, and the turbo-jpeg tests silently tested
Pillow. Install the official libjpeg-turbo 3.2.0 package (checksum pinned)
on Linux and Homebrew's jpeg-turbo on macOS, and fail the job if turbo-jpeg
still falls back to Pillow. The README's Ubuntu instructions had the same
problem and now point to the official package.
Add pytest-benchmark to the dev extra, and benchmark
VtkRemoteControlledArea.img_cols_rows on a 1920x1080 frame separately from
encoding one captured frame with each encoder, so encoder differences
aren't hidden by capture time (CI renders in software). Rendering is
finished before each timed capture, and the scene is a colored mesh with
its edges over a gradient covering most of the frame, so encoding sees
realistic detail rather than flat background. CI saves the results as a
Linux artifact so later changes have a baseline to compare against.
Render a non-square window whose four viewports have distinct backgrounds
and check each quadrant's color in the img_cols_rows array and in the
decoded output of every encoder, so a flipped, mirrored or transposed frame
fails. Also check that encoded frames have no alpha channel and that a
frame is not overwritten by the next capture.

Check that every encoder gives the same bytes for non-contiguous RGB
arrays (views of RGBA, bottom-up, mirrored, transposed, channel-offset,
strided, Fortran order) as for a contiguous copy. These need no rendering,
so they live in their own module and also run on macOS and Windows CI.

The frame size check (cols, rows, and the encoders' meta w/h) is a strict
xfail: the VTK RCA unpacks GetDimensions() (width, height) as rows, cols and
so returns the height as cols, unlike the protocol and the vanilla example.
img_cols_rows unpacked vtkImageData.GetDimensions(), which is (width,
height, depth), as rows, cols, so it returned the height as cols and the
width as rows, unlike the protocol and the vanilla example. The array
shape was right, but the encoders' meta reported w and h swapped for
non-square windows.
VTK's Linux wheels try EGL before OSMesa when there is no display. EGL
isn't installed on the runner, so every render window logged "Failed to
load EGL!" before falling back to OSMesa. Select OSMesa directly by
setting VTK_DEFAULT_OPENGL_WINDOW in the Linux-only OSMesa install step;
the rendering backend is unchanged.
Capture RGBA from vtkWindowToImageFilter and flip it into a new buffer,
returning its RGB channels as a view. Pillow and PyTurboJPEG can then
read the 4-byte pixels in place (Image.frombuffer "RGBX" /
TJPF_RGBX) instead of Pillow copying the frame via Image.fromarray.

The returned array is still a top-down RGB array, so other RCAs, the
non-JPEG formats and the multiprocessing path are unchanged: VTK's alpha
(0 on the background) never reaches the encoders, and output is
byte-identical to before for jpeg, turbo-jpeg, png, webp and avif.

The flip no longer writes back into the VTK-owned buffer.
PyTurboJPEG defaults to 4:2:2 while Pillow uses 4:2:0, so turbo-jpeg
frames were larger and slower to encode than jpeg ones. With 4:2:0 both
encoders produce frames of the same size.

The test is skipped unless PyTurboJPEG can load libjpeg-turbo >= 3.0.
@user27182 user27182 closed this Oct 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant