joaomoreno / gifcap

Capture your screen to a GIF in your browser

Home Page:https://gifcap.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

OOM - white screen and exception when stopping recording

Tyriar opened this issue · comments

This was on a gif that I tried to record after accidentally leaving it recording for 5 minutes. Reloading/closing+reopening the tab doesn't fix the problem.

Screen Shot 2021-06-22 at 6 44 51 AM

Screen Shot 2021-06-22 at 6 47 35 AM

main.js:1 Uncaught RangeError: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': Out of memory at ImageData creation
    at Worker.u.onmessage (main.js:1)
main.js:1 TypeError: Cannot read property 'timestamp' of undefined
    at new Gt (main.js:1)
    at b (main.js:1)
    at C (main.js:1)
    at d (main.js:1)
    at L (main.js:1)
    at R (main.js:1)
    at q (main.js:1)
    at L (main.js:1)
    at R (main.js:1)
    at q (main.js:1)

Screen Shot 2021-06-22 at 6 43 53 AM

Closing and reopening Edge freed the memory and I can use gifcap again

Unsure of what we could do here. Should we have a soft limit on the memory? Is there anyway I can figure out we're getting close to OOM? An event on OOM would be too late.

Also, reloading don't work I'm guessing cause they reuse the same engine/scope.

Any idea why the memory wasn't getting freed? At the least you should catch getImageData and show the error in the UI

Well, 5 minutes of recording. That's a lot of memory. I'm guessing it hit OOM and then just hangs in there.

I'm guessing OOM errors could surface from all over the place, so wrapping around getImageData wouldn't be suficient. 🤔

I mean if we can't free the memory, a message on screen would be better than needing to dig through devtools.

What about something like this during recording?

  1. Catch the RangeError on getImageData.
  2. Trim back some frames to regain some memory for the apps playback process.
  3. Stop the recording, with a message above it that the browser ran out of memory and had to stop early.

If the memory error is caught during recording, it is unlikely to occur again during trimming/cropping unless the user has other memory changes on their system. Those changes are outside of the application's control though and I am not sure if they should try to be accounted for.