Looks like CreateScreenshotUsingRenderTarget is broken on Mac and iOS while using Safari.
I ran across this
issue that seemed similar, however, the above function throws errors on both the latest version of macOS and iOS (with fairly new devices, that should definitely be WebGL 2 capable).
This used to work with no changes on our part. We updated from Babylon 5.38.0 to 6.9.0 and started seeing the issue, if that helps narrow down where this may of started.
We fixed an issue with dump tools and premultiplied alpha 8 months ago (
Fix dump tools premultiplied alpha. by sebavan · Pull Request #13251 · BabylonJS/Babylon.js · GitHub), but that change was already in 5.38.0 (first merged in 5.33.0).
There has been no changes in the 3 files involved (
screenshotTools.ts) since then, so I’m not sure what the problem could be…
For testing purpose, I have updated your PG to use the old code before 5.33.0:
Does it work?
@Evgeni_Popov Yup, that does seem to work
I’m not sure to understand why, as it seems nothing changes in the screenshot code between 5.33.0 and now…
Are you sure you weren’t using a version older than 5.33.0 previously?
Also, it could help to know what are the errors thrown by Safari with the current version.
We are trying to get a more specific version where it broke. So far we have determined that it is working up to 5.57.1.
Ohhhh it would make sense as Safari does not support webgl in offscreen canvas before 17
@Evgeni_Popov any way to add a fallback if the creation of the context is failing ?
Ah, I seem to have failed looking at the history of these files, obviously there have been changes over the last few months…
Perhaps we could add a static boolean
DumpTools.DisableOffscreenCanvas that users could set before using the screenshot APIs, to create a
canvas instead of an
[EDIT] Or, if we’re sure that context creation fails and the
ThinEngine constructor throws an exception (which seems to be the case in the screenshot), I could catch it and use a canvas instead, removing the need for the new static…
I do prefer to the second option as we could remove this code path when supported everywhere without breaking changes or leftovers APIs.
@EricB Can you test this PG?
If it’s ok, I will make a PR.
In case the fix is ok, here’s the PR:
03:05PM - 18 Jul 23 UTC
@Evgeni_Popov Yup, looks like that is working on Safari on both a Mac and iOS!