Image export not working

[calumk]

// 3d conversion works no problem
./mayo-conv KC.stp --export KC.gltf

//image export hangs
./mayo-conv KC.stp --export KC.jpeg

calumk@mbp mayo-only % ./mayo-conv KC.stp --export KC.jpeg
100% Exporting KC.jpeg...
100% Imported

(hangs, file is not generated)

Same on the desktop app

[HuguesDelorme]

This may affect only macOS platform, couldn't reproduce on Windows
Will test with my macos Monterey virtual machine soon and let you know the results

[calumk]

Thanks for looking into it

[HuguesDelorme]

When trying to export to png image, Mayo crashes on macOS Monterey x64 (VM) with message :
Assertion failed: (NSViewIsCurrentlyBuildingLayerTreeForDisplay() != currentlyBuildingLayerTree), function NSViewIsCurrentlyBuildingLayerTreeForDisplay, file NSView.m, line 13477

@calumk This is a different behavior, probably caused by different OS versions and hardware. I need to get a physical Apple machine for real testing(eg Apple Mac mini M1)

[calumk]

Root-caused this on macOS 26.5 arm64 (M-series), Qt 6.10.2, OpenCascade 7.9.3. Fix offered in #411.

Attribution: the investigation, code and this comment were written by Claude Opus 5 operating/steered as instructed on behalf of @calumk. Reviewed before posting.

@HuguesDelorme — your NSView.m:13477 assertion and my hang are the same bug presenting differently, so you may not need to source an Apple machine to make progress. Details below.

There are three independent defects stacked here. Fixing any one alone leaves export broken, which is why this looked inconsistent.

1. Cocoa_Window cannot be used for offscreen rendering. graphicsCreateVirtualWindow() creates a Cocoa_Window, whose constructor throws Aspect_WindowDefinitionError("Cocoa application should be instantiated before window") when NSApp is null — always true in mayo-conv, which builds a QCoreApplication. lldb throw breakpoint:

Cocoa_Window::Cocoa_Window + 464
Mayo::graphicsCreateVirtualWindow
Mayo::IO::ImageWriter::createV3dView
Mayo::IO::ImageWriter::writeFile      ← thread #4 (std::async worker)

Cocoa_Window also allocates a real on-screen NSWindow and retains its contentView. Export runs on a worker thread, and touching NSView off the main thread is illegal — that is your assertion crash. In the GUI NSApp exists, so the constructor gets further before dying on the threading violation; in mayo-conv it throws immediately. Same root cause, two symptoms, and it explains the OS/hardware difference you saw.

Fix: Aspect_NeutralWindow on macOS. Mayo already uses it for Android and in qtopengl_utils.cpp (OcctNeutralWindow).

2. The exception became an infinite hang — this is the "hangs, file is not generated" part. TaskManager::Private::execEntity() calls the job unguarded, so the throw escapes into the std::async future, which is stored but never waited on → exception silently swallowed → signalEnded never fires → exportTaskCount never hits zero → QCoreApplication::exec() blocks forever in poll(). Worth noting independently of macOS: any OCCT throw in an export path currently hangs mayo-conv rather than reporting an error.

3. ToPixMap() then failed on a stale GL error (only visible after fixing 1):

2D texture 128x128 IF: GL_SRGB8_ALPHA8 PF: GL_RGBA DT: GL_UNSIGNED_BYTE
can not be created with error GL_INVALID_FRAMEBUFFER_OPERATION [:color]

A drawable-less context has an incomplete default framebuffer, so OCCT's own glDrawBuffer(GL_BACK) in OpenGl_Window::init() raises GL_INVALID_FRAMEBUFFER_OPERATION and never clears it; OpenGl_Texture::Init() later reads that stale error and wrongly reports failure. Verified a false negative with a standalone probe — a view-less NSOpenGLContext created the identical texture with error 0x0 and FBO status = GL_FRAMEBUFFER_COMPLETE. Fix is a ResetErrors() immediately before ToPixMap() (at view creation is too early — Redraw() re-raises it).

Verified after the fix: STEP/IGES/BREP/OBJ/STL/PLY/glTF inputs, up to 3840×2160, concurrent exports, and invalid-input error paths. No hang, no crash, images visually correct. Test suite 225 passed / 0 failed. Not tested on Linux or Windows.

Two side notes:

• A fourth, unrelated bug surfaced once export worked: BRep inputs render as wireframe because mayo-conv never meshes them for image export (formatProvidesMesh() excludes Format_Image). CLI-only — the GUI passes formatProvidesBRep and is unaffected. Filed separately as mayo-conv: image export renders BRep shapes as wireframe (no meshing) #412 with a one-line fix, so as not to muddle this issue.
• Homebrew's OCCT ships without FreeImage, so Image_AlienPixMap::Save() writes Netpbm/PPM data regardless of extension — a .png from a stock Homebrew build is not actually a PNG. OCCT packaging matter rather than a Mayo bug, but it will confuse macOS users.