firejail version 0.9.66
Compile time support:
- always force nonewprivs support is disabled
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- D-BUS proxy support is enabled
- file and directory whitelisting support is enabled
- file transfer support is enabled
- firetunnel support is enabled
- networking support is enabled
- output logging is enabled
- overlayfs support is disabled
- private-home support is enabled
- private-cache and tmpfs as user enabled
- SELinux support is enabled
- user namespace support is enabled
- X11 sandboxing support is enabled
but I couldnât reproduce the issue. I will look into installing your exact version.
In the meantime i made a new build with webgl-lint enabled, maybe this can give us a better error report? https://3d7.rblb.it
But is it still a 3060?
Is there any chance you can update the drivers?
If not i will try to build a test case that is pure webgl and see if we can at least isolate the issue to the 32x32 (and < ?) framebuffer.
We plan to update anyway, but after finish things working on. But not just now.
Based on all info it might be driver version or something that cause issue. But idk really.
got info that model rotation works kinda slow on other machine.(but maybe firejail slow down it)
Sketchfab works fine tho for me, but i understand its much different approach there.
In summary, if its just my machine having problem, its not so important it seems.
Would be cool if more people test if it work fine for them.
Tho would be cool if it work here too.
That was webgl-lint, since it checks for error on every gl call. (Also note that all the domains point to the same page to which i am redeploying, i am just adding them to bypass caching just in case).
I made a new build, this one bakes a bigger env map and cuts at 64x64 mip level, if we are correct, this one should work: https://3d8.rblb.it
That was webgl-lint, since it checks for error on every gl call. (Also note that all the domains point to the same page to which i am redeploying, i am just adding them to bypass caching just in case).
ah, nice, so it can work much faster.
still(for my machine ofc): (and yes i open new link with 8 as version)
jmeapp.js:101 java.lang.IllegalStateException: Framebuffer object format is unsupported by the video hardware.
Oh i see, always on the first level. So the issue is not with the mipmap size, but actually with binding the framebuffer to a mip level. I will make some researches to see if there is a workaround.
One of the earlier builds did not, but now itâs working fine for me:
Linux Mint 21.1
Firefox 113.0.2 (64-bit) (no firejail)
AMD Radeon RX 6500 XT (driver 23.0.4)
FYSA: it works for me also. From the first time I looked to now. Still works. Better now than before, maybe. (Larger in the frame and seems to drag a little smoother but to be honest I didnât poke at it much before either.)
Windows 7 (yes, I know)
Firefox 113.0.1 (64-bit)
GeForce GTX 960
That was webgl-lint, since it checks for error on every gl call. (Also note that all the domains point to the same page to which i am redeploying, i am just adding them to bypass caching just in case).
Iâve deployed a temporary workaround, the new code should catch the exception and print a warning.
In this way in these (supposedly) broken drivers the scene is rendered with only the top mip level resulting in everything being a bit too shiny, but at least it wonât crash⌠can you try it: https://3d9.rblb.it ?