display.save GPU hang occurred

[ymmtny]

Does anyone encounter a problem of display.save?

Solar2D 2022.3665 (2022.2.23)

Tested display.save of SampleCode/Strorage/ScreenCaptureToFile

File entireScreen.jpg was saved in the documents directory.
Feb 26 15:08:35.159 GPU hang occurred, CoreAnalytics returned false

The captured image is black too

My mac is MacBook Pro (13-inch, 2020) Big Sur

[ymmtny]

maybe related

display.capture adds a 1 pixel white line on right and bottom edge

Urgent Issue with display.capture saving to the Photo Library! When I use display.capture to save a group object to the Photo Library it adds a 1 pixel white line on right and bottom edge instead of the color that is supposed to be there. Next to the white line is about 50% grayed color pixel line. Also it only exports JPGs but the documentation says it can do PNG but there is no info on how to set that parameter. I need to save without any anti-aliasing so PNG format would probably work best. …

[StarCrunch]

Hi.

There seem to be quite a few capture issues recently. (There were already a few, but there’s been an uptick. I’m not certain what changed and when.) Some streaming software might also be affected; there was some Discord discussion about that.

I made a guess here that OpenGL’s packer might have became more stringent. Maybe it’s now balking at not-quite-spec things, whereas it was letting them go before? (I think Windows was already this way; annoyingly, on other issues it’s been the other way around. )

I wrote a Vulkan backend a while back. According to somebody who tested with a major project, its capture feature seems to be robust against these sorts of issues. This includes streaming with OBS, where I’m told he was running into problems with GL.

Solar’s OpenGL backend is built on glReadPixels. My best guess is that we have a “packing” issue. I don’t have a ready use case to verify this, but I’m guessing that if captureWidth % 4 == 0 is NOT true, a problem might arise… or not, if we’re “lucky”. (In my Bytemap plugin on Windows,—where we “unpack”—I had to add a dummy alpha channel to RGB “external” textures, thus my suspicions. I wonder if this might be behind the mysterious “multiple-of-4” width requirement on masks.)

(If this NEVER occurs on mobile, where RGBA is used unconditionally, I lean even more this way.)

If this analysis is correct, the glReadPixels line needs to be preceded by something like glPixelStorei( GL_PACK_ALIGNMENT, BitsForFormat( format ) ).

The BitsForFormat() function doesn’t exist, but outside OpenGL ES would roughly involve the logic here: RGBA and friends would be 4 bytes per pixel, RGB would have 3, anything else 1. We would first multiply this value by the width passed to glReadPixels. If (width * bpp) % 4 == 0, 4 is our alignment; otherwise try 3, and finally 1.

I can’t conveniently test this at the moment, but I’ll pass it along.

[StarCrunch]

Hi @ymmtny. Are you still able to reproduce this error? (I DM’d you on Discord about this as well.)

This new issue mentions having half of your problem, i.e. a black capture. Maybe there’s something identifiable going on.

Would you be able to build from source? There is something (shortly after the file-saving, per your timestamps) that would go wrong, if it happened. (This deals with restoring the framebuffer.)

I don’t see any issues on my fairly new Air, with Monterey. (The “if” does not occur on mine.)

---

(By the way, my earlier analysis was wrong. There always seems to be 4 bytes-per-pixel format on Mac.)