Skip to content

Resize against sizeElement, notViewElement#148

Merged
almarklein merged 1 commit into
vispy:mainfrom
gselzer:resize-without-border
Apr 2, 2026
Merged

Resize against sizeElement, notViewElement#148
almarklein merged 1 commit into
vispy:mainfrom
gselzer:resize-without-border

Conversation

@gselzer
Copy link
Copy Markdown
Contributor

@gselzer gselzer commented Apr 1, 2026

Hi!

I've been dealing with examples over in pyapp-kit/scenex where, on the newest release of jupyter-rfb, my views cotinuously get smaller. I've tracked it down to a simple example, and the changeset here fixes things.

MCVE reproducing error:

  1. Check out main:
  2. uv run jupyter notebook examples/pygfx1.ipynb (with pygfx installed)
  3. Run the existing cell, generating the canvas (tangentially, when I first run the canvas, it's all gray, but interacting with the canvas draws an image)
  4. In a new cell, run:
disp.canvas.set_logical_size(400, 400)
  1. In a new cell, run:
disp.canvas.get_logical_size()

Without these changes, it prints out (398.0, 398.0)

Through some Claude-assisted digging, it seems like this is because of this line in the CSS - removing this line makes the example print out (400.0, 400.0).

This PR instead changes the target of the BaseRenderView._resizeObserver to listen to the sizeElement instead of the viewElement, which takes the border out of play.

There are probably other ways to fix this - I don't have a comprehensive understanding of jupyter_rfb - so please feel free to suggest alternative fixes. I also don't know how to go about testing this fix, so pointers there would be appreciated.

@almarklein
Copy link
Copy Markdown
Member

Thanks for the report and the suggested fix!

I took a different approach to fixing this, because it's important that the reported size matches the viewElement, because in GPU apis we want to know the exact physical size. I fixed it upstream in pygfx/renderview#16, I'll copy the code over to here soon.

@almarklein almarklein merged commit 01cff47 into vispy:main Apr 2, 2026
15 checks passed
@almarklein
Copy link
Copy Markdown
Member

Oh crap, merged the wrong PR 😆 Anyway, I'll overwrite the same file soon.

gselzer added a commit to gselzer/scenex that referenced this pull request Apr 8, 2026
It switches to anywidget, which is great, except for a couple of bugs
that break usage. See vispy/jupyter_rfb#148 and
also kinda vispy/jupyter_rfb#151. Once both of
those are resolved (currently only the first is) we should just enforce
a new minimum bound >1.0.2.

And then we may want to consider renaming the jupyter backend, because
anywidget might be better.
gselzer added a commit to pyapp-kit/scenex that referenced this pull request Apr 9, 2026
* Avoid jupyter-rfb 1.0.2

It switches to anywidget, which is great, except for a couple of bugs
that break usage. See vispy/jupyter_rfb#148 and
also kinda vispy/jupyter_rfb#151. Once both of
those are resolved (currently only the first is) we should just enforce
a new minimum bound >1.0.2.

And then we may want to consider renaming the jupyter backend, because
anywidget might be better.

* Linting fixes
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.

2 participants