CLI commands of MaterialX viewer cause dock icon to appear on macOS

[sebastianrath]

Using the CLI of the MaterialX viewer show the dock icon for a few seconds.

Especially async batch scripts cause the dock to look like this:

Example usage to bake a texture:

$ bin/MaterialXView --material test.mtlx --bakeFilename ~foo.mtlx

[jstone-lucasfilm]

@seb-mtl Thanks for reporting this, and it sounds like our command-line handling of the MaterialX viewer could be cleaned up. In our own production usage, we instead focus on Python scripts for MaterialX texture baking, and that's another option that you might consider:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/python/Scripts/baketextures.py

This approach gives you more control over the texture baking options, and it removes all of the overhead associated with launching an application and then shutting it down again.

[sebastianrath]

Thanks for the feedback! Interestingly this also happens with baketextures.py, but now the app Icon of Python.app(see full path below) shows up in the dock. I execute the script through the Terminal (left icon), and while the texture is baked the right icon appears.

I probably have some time next week to dig into it.

/usr/local/Cellar/[email protected]/3.7.13/Frameworks/Python.framework/Versions/3.7/Resources/Python.app

[sebastianrath]

Here is a quick update. The dock icon is created by the following function call in the Python script:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/41c5834fbc9de99c5c312262365f37056e4c65f1/python/Scripts/baketextures.py#L55

This eventually results in executing NSApplicationLoad(); which creates the additional icon.

https://github.com/AcademySoftwareFoundation/MaterialX/blob/41c5834fbc9de99c5c312262365f37056e4c65f1/source/MaterialXRenderHw/WindowCocoaWrappers.m#L19-L25

Callstack

#0	WindowCocoaWrappers.m:28
#1	MaterialX_v1_38_4::SimpleWindow::initialize
#2	MaterialX_v1_38_4::GlslRenderer::initialize
#3	MaterialX_v1_38_4::TextureBaker::TextureBaker
#4	MaterialX_v1_38_4::TextureBaker::TextureBaker
#5	MaterialX_v1_38_4::TextureBaker::create
#6	baketextures.py:55

@bernardkwok You added NSApplicationLoad(), is this also needed when executed through the Python API?

[kwokcb]

Hi @seb-mtl,

Thanks for tracing this through. This was written a long time ago for command line testing (and wasn't ever wrapped through a Python wrapper) so would need to take a look. ( BTW, is this your post? https://developer.apple.com/forums/thread/703527 ?)

Believe generalized non-OpenGL based baking is something on queue, or at least the bake API should be generalized @jstone-lucasfilm (As mentioned at the last TSC ?) but that's a bit orthogonal as if another command line render is called this same symptom may also show up.

[sebastianrath]

@kwokcb Indeed, it's my post, great catch :-) .. and thanks for the background info! I am trying to reproduce the issue with a minimal CLI example. I am not sure why setting the activation policy triggers the explained effect in a command-line tool vs. an app-bundle. So unless I'm missing something completely obvious here I hope that the guys in the Apple forum can shed some light on it.

[jstone-lucasfilm]

@sebastianrath I'll mark this issue as resolved now that #1132 has been merged to main, but let us know if you run into similar issues in the future.