New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<View />
Component assumes that the canvas is full screen
#944
Comments
view bounds are being calculated here: https://github.com/pmndrs/drei/blob/master/src/web/View.tsx#L111 could you look into it? i have little understanding how it has to be done properly. @FarazzShaikh i think ... that instead of using getBoundingClientRect we should probably use this: https://github.com/pmndrs/react-use-measure it's the same lib that calculates r3f canvas bounds. |
Sure will look into it as well as the other issues with View |
@kmannislands To make sure I understand the issue correctly i have hard coded the fix, this is the expected result yes? and this the broken In both demos, the red boxes are the @drcmda we should expose the canvas bounds ( |
@drcmda yep, I had a similar user land implementation (I called mine As a quick and very hacky/non-performant PoC, something like this works: // Obviously bad:
let elem: HTMLElement | null = null;
function getCanvasBoundingRect(): DOMRect {
if (!elem) {
elem = document.querySelector('canvas');
}
return elem!.getBoundingClientRect();
}
// Computing correct positions for the View inside the use-frame:
// Includes information on the page position of the canvas, not just dimension:
const canvasSize = getCanvasBoundingRect();
const { left: trackElementLeft, right, top, bottom: trackElementBottom, width, height } = rect.current;
const left = trackElementLeft - canvasSize.left;
const bottom = canvasSize.bottom - trackElementBottom;
// ...
state.gl.setViewport(left, bottom, width, height);
state.gl.setScissor(left, bottom, width, height); Happy to send a PR, just need some guidance on the best way to determine Canvas position |
@FarazzShaikh yes, that's exactly what I was seeing. Thanks for the example there. |
Let’s just add back |
I've taken a pass at adding https://github.com/kmannislands/react-three-fiber/pull/1/files @drcmda @FarazzShaikh is this a change that It's an interface change in that I adjusted |
Your PR is sane, can you PR it into r3f? Im unsure why the Will keep this issue open and once these props are are added to r3f it is an easy solution here. |
Okay, opened the PR in to r3f. Assuming that is accepted and makes it in to the next release, what should the strategy be on my drei-side PR? I can mark drei's peer requirement as requiring newer than the released version of r3f with Another approach that I find preferable would be to adapt the |
If it makes it into v8 then yes a fallback to current behavior with a console warning would be the way to go If it makes it into v9 then we can bump peer deps. Btw would you like me to assign this issue in Drei to you? |
@FarazzShaikh makes sense. Yes sure |
Hello, is there a workaround for now? A project at my workplace depends on this. I would like to help if possible. |
pmndrs/react-three-fiber#2339 was just shipped into 8.1.0. |
Hey folks! Is the fix in https://github.com/pmndrs/react-three-fiber/pull/2339/files#diff-42e46ec762930e1485e849404cfda91d327e6ee4891ebbb7e9bc7c09f2cd01d0R285 meant to be checking clientTop? Is the border width the correct value to be looking at? I would have imagined something similar to your original POC would have been needed? #944 (comment) Alternatively exposing the canvas element in For context I had similar problems to this, where a scroll container (not body) would have the wrong position as it wasn't taking the scroll position of the container into account. I've fixed this for now by forking View and passing the canvas top data after calling getBoundingClientRect on it (similar to your POC). |
No indeed it is not! Good catch. I've raised a PR to fix that discrepancy: pmndrs/react-three-fiber#2406 Seems that this would only impact users of Agree that exposing the |
🎉 This issue has been resolved in version 9.42.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
three
version: r139@react-three/fiber
version: 8.x (any compatible with createPortal state "enclave")@react-three/drei
version: 9.1.3 (any including View component)node
version: 16npm
(oryarn
) version: 3.2.0Problem description:
The nifty new View component seems to bake-in the assumption that the canvas is fullscreen. If the r3f canvas is not fullscreen, the
View
s within it are offset from the top/left by the same amount that the whole canvas is.Relevant code:
I've modified one of the
<View />
examples to demonstrate this.https://codesandbox.io/s/view-skissor-forked-k46ley?file=/src/App.js
Suggested solution:
When calculating the scissor viewport in the
<View />
component, the calculations for bottom and left should factor in the canvas element's own bounding rect as well as the "track" elements bounding rect.Not sure what the best way to go about getting the canvas's bounding rect--it's no longer exposed on the
state.size
property like it used to be in older r3f versions (now it's just height, width. Used to includetop
andleft
).The text was updated successfully, but these errors were encountered: