Description
Description
Problem
Events captured by the SDK some times contain blank or black screenshots. This obviously makes them less than useful.
Context
Based on the Unity documentation, capturing screenshots should be done at the end of rendering - typically EndOfFrame
. Capturing screenshots at any time before that leads to unpredictable and undefined results. Our ScreenshotEventProcessor
does exactly that. It captures the screen at the exact time of the error.
Proposal
The fix for this is less than straight forward. We cannot halt the SDK's execution until the end-of-frame. And we cannot use Unity's yield new WaitForEndOfFrame()
from within the SDK.
Attachments can be sent separately
The idea now is to separate screenshot-capture from event-processing. A possible approach would be to have the ScreenshotEventProcessor
note the event-ID and pass this on to our SentryMonoBehaviour
where we do have access to yield new WaitForEndOfFrame()
and send the attachment for event-ID the processor held.
This comes with the issue that the eventprocessor has no way of knowing whether the event got dropped or not and not having access to the hub to fetch the LastEventId
. But SdkIntegrations
do have access to the hub.
A possible solution could be
- The
ScreenshotSdkIntegration
hooks into the update loop forEndOfFrame
via adding itself toPlayerLoop.GetCurrentPlayerLoop()
- The
ScreenshotProcessor
stores the event ID - In the next
EndOfFrame
update theScrenshotSdkIntegration
checks the stored ID vs theLastId
and captures a screenshot.
While at it, we can take a look at reading pixels asynchronously when capturing a screenshot.
Note, that the PlayerLoop.GetCurrentPlayerLoop()
is only accessible starting from version 2021 and newer
.
Metadata
Metadata
Assignees
Type
Projects
Status