Enable antialising for screenshots if enabled in user configuration

[daniel-wer]

Easy now that we use webgl 2. See https://discourse.threejs.org/t/why-is-a-custom-fbo-not-antialiased/1329/3 and https://github.com/mrdoob/three.js/pull/23455/changes#diff-5b25cb6d07a2d314fa35eb2138d99f2484837dcc079fd06e0cb108e8aa70618aR1983 (that's also where I got the samples=4 from).

This actually also fixed the colored borders of the viewports only showing up for two of the four sides for me 🤷 Still, it's only used if users enabled antialiasing.

URL of deployed dev instance (used for testing):

• https://___.webknossos.xyz

Steps to test:

• Run the screenshot tests (First try, Second try)
• Open a dataset, slightly rotate the 3d viewport so the dataset borders are not axis-aligned and take screenshots (with + without antialiasing enabled)
• Test in arbitrary view mode as well
• Test that the node picking continues to work if antialiasing is enabled

Issues:

• fixes Antialias screenshots #5323

---

(Please delete unneeded items, merge only when none are left open)

• Added changelog entry (create a $PR_NUMBER.md file in unreleased_changes or use ./tools/create-changelog-entry.py)
• Removed dev-only changes like prints and application.conf edits
• Considered common edge cases

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds an optional enableAntialiasing parameter to renderToTexture and enables MSAA (samples = 4) when that flag is true; screenshot code now calls renderToTexture(..., enableAntialiasing = true) so screenshots are rendered with antialiasing.

Changes

Cohort / File(s)	Summary
Rendering utility frontend/javascripts/viewer/view/rendering_utils.ts	Adds optional parameter enableAntialiasing: boolean = false to renderToTexture; when true, sets render target samples = 4 (MSAA). downloadScreenshot updated to call renderToTexture with enableAntialiasing = true.
Changelog unreleased_changes/9363.md	Documents that anti-aliasing is enabled for screenshots.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested labels

frontend, testing

Suggested reviewers

• philippotto

Poem

🐰 I hopped through pixels, small and bright,
I nudged the samples, four by night,
Screens now smooth where edges played,
A rabbit's stamp on every shade ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: enabling antialiasing for screenshots based on user configuration.
Linked Issues check	✅ Passed	The PR successfully addresses issue #5323 by implementing antialiased screenshots using WebGL 2 multisampling (MSAA with samples=4), directly solving the ragged edges problem described in the issue.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing antialiased screenshots and are within the scope of issue #5323.
Description check	✅ Passed	The pull request description clearly describes enabling antialiasing for screenshots when WebGL 2 is used, with references to technical discussions and implementation details.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch antialiased-screenshots

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/javascripts/viewer/view/rendering_utils.ts`:
- Line 101: The renderToTexture path is enabling MSAA unconditionally when
state.userConfiguration.antialiasRendering is true, which corrupts ID-picking;
add a new boolean parameter enableAntialias (default false) to the
renderToTexture function, change the MSAA line to only set renderTarget.samples
= 4 when enableAntialias && state.userConfiguration.antialiasRendering, and
update the screenshot export call (the caller at the screenshot/export path) to
pass enableAntialias = true; leave all other callers (e.g., ID-picking usages
from skeleton_handlers.ts and arbitrary_view.ts) unchanged so they continue to
call renderToTexture with the default (false).

In `@unreleased_changes/9363.md`:
- Line 2: Fix the typo in the changelog by replacing the misspelled word
"antialising" with "antialiasing" in the text of unreleased_changes/9363.md
(search for the exact token "antialising" to locate the line).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f446761f-d800-49c9-9ece-874b532237ef

📥 Commits

Reviewing files that changed from the base of the PR and between 7a90099 and fc2d6bd.

📒 Files selected for processing (2)

• frontend/javascripts/viewer/view/rendering_utils.ts
• unreleased_changes/9363.md

[philippotto]

works well for me 👍 screenshot tests failed, though (havent looked into that).

Still, it's only used if users enabled antialiasing.

I wonder whether we should always enable this? I always disable anti-aliasing for performance reason. However, performance is mostly irrelevant for creating screenshots (instead, rendering quality is typically a priority). while comparing two screenshots (with and without AA), I only noticed pixel differences at geometries (the actual voxel data looked exactly the same). so, I don't see much harm in always enabling AA for screenshots. what do you think?

[daniel-wer]

I wonder whether we should always enable this?

Makes a lot of sense 👍

[daniel-wer]

The screenshot tests have been failing for a while 🙈 The changes look to be from the PR that adapted the node positioning to be in the voxel center. I'll have a look at regenerating them.

[daniel-wer]

@philippotto I recreated the screenshots on master and then ran the tests for this branch which was successful, so no changes due to this branch. I didn't spot any large differences looking at the diff in this PR, except for what looks like remnants of a toast at the upper right of the third viewport - do you know where that comes from? I remember having seen that before, but I don't recall the fix.
Also, I noticed that some of the checked-in screenshots were renamed (- replaced by _) by accident in an earlier PR, so they have not been compared at all since then.

[daniel-wer]

On a closer look, for two datasets a white segment seems to have appeared in the top left center of the XY viewport on the new screenshots:
frontend/javascripts/test/screenshots/dtype_uint32_segmentation_zoomed_in_selective_segment.png
frontend/javascripts/test/screenshots/dtype_uint64_segmentation_zoomed_in_selective_segment.png

I can confirm this via this link: https://antialiasedscreenshots.webknossos.xyz/annotations/69b9e4ff010000e10012a40d#512,1,0,0,0.047
when clicking on the green segment 2181570682 at the right half of the XY viewport to register it and enabling "Hide unlisted segments". Is this a regression on master?