Boolean operations: "Requested capacity is too large" on MacOs Sonoma.

[ubaldot]

Description of bug

../../../../../../src/cpp/skia-builder/skia/src/base/SkContainers.cpp:106: fatal error: "Requested capacity is too large." zsh: trace trap manim discord.py -pql --disable_caching -v WARNING

How to reproduce the issue

import manim as mn

class Example(mn.Scene):
    def construct(self):
        sq = mn.Square(color=mn.RED, fill_opacity=1)
        sq.move_to([-2, 0, 0])
        cr = mn.Circle(color=mn.BLUE, fill_opacity=1)
        cr.move_to([-1.3, 0.7, 0])
        un = mn.Difference(sq, cr, color=mn.GREEN, fill_opacity=1)
        un.move_to([1.5, 0, 0])
        self.add(sq, cr, un)

System specifications

System Details

• macOS 14.0 (Sonoma)):
• RAM: 32 GB
• Python version (python/py/python3 --version): python 3.11.6
• Manim v0.18.0 installed with conda.

[behackl]

Can't reproduce on MacOS 12.3 / Monterey. Might be a Sonoma-specific issue.

RAM: 1TB

Are you sure? What sort of machine are you working on? 😱

[ubaldot]

Damn. I cannot downgrade to Monterey (and to be honest I don't even want to do that! :D).
Let's wait if someone has Sonoma and can tackle this issue.

Are you sure? What sort of machine are you working on? 😱

Oooops! That is the HD! :D
The RAM is 32 GB :D I am going to correct my post.

[ruze00]

I have the same issue on a new git-story install. My machine is an M2 Mac pro with 32GB RAM and Sonoma. Using a conda install of git-story.

../../../../../../src/cpp/skia-builder/skia/src/base/SkContainers.cpp:106: fatal error: "Requested capacity is too large."
[1]    61446 trace trap  git-story
/Users/base/anaconda3/envs/mer/lib/python3.11/multiprocessing/resource_tracker.py:254: UserWarning: resource_tracker: There appear to be 1 leaked semaphore objects to clean up at shutdown
  warnings.warn('resource_tracker: There appear to be %d '

Hope this helps and someone can fix it. Seems to be in skia.

[ubaldot]

Given that I kinda will need this feature soon, I try to take a look at the source code, but the available time is unfortunately always limited. :(

TLDR: I think it is just a matter of time and this issue will be fixed somewhere, so perhaps the best would be just to wait. :)

Some findings and personal considerations:
What I found out is that the boolean_ops module (the one in charge of allowing users to perform boolean operations on Mobjects) relies on Skia, which is a google tool for 2D graphics. However, to access this tools we need some python binding and Manim is using skia-pathops for the purpose. By looking at the code, the process to perform boolean operations seems to be:

Mobjects -> skia-pathops -> Skia (and back)

The cause of the issue that we are encountering is somewhere in this chain, but a thorough investigation would be needed to figure out where exactly.
However, I am pretty sure that the very same issue will hit some dev working in some point of such a chain(I don't know in which point of the chain) and he/she will (hopefully) fix it.
I also run some pytest locally and they fail the boolean operation tests. This doesn't happen yet in the github workflow because macos-latest is not v14. However, sooner or later the action will be updated and I don't know how the Manim Community will address the issue (but in the meantime the issue may be solved elsewhere and there will be zero problems for the Manim workflow).

As a personal consideration, I noticed that Skia is used only for boolean ops (I may be wrong though) which is a very tiny part of Manim and yet there are two dependencies: skia-pathops and Skia. I am not a fan of having too many dependencies, plus Google is notorious to suddenly drop support for its own tools. Skia do much more that just boolean operations and using it only for boolean_ops sounds a bit to overkill, perhaps there is a smaller size solution that could fit better there. Finally, Skia is a 2D whereas in Manim pretty much everything is 3D.

In the light of that, perhaps a good long-term idea would be to avoid having such a chain dependency and to cook a "in-house" solution instead, or to use a smaller dependencies where we could somehow have more control like for example this - I don't think we can have any influence on Skia itself.

I understand that it could take long time for "in-house" solution and I am aware that the "blanket is always short", but IMO this could be a good MsC thesis work for some student. ;-)

[uwezi]

I did a quick search since binary operations on polygons (that's more or less what we do, modulo the fact that our edges are usually Bezier curves) is very common in CAD. There are quite some libraries and algorithms out there, this one seems to stand out: Pyclipr is a Python library offering the functionality of the Clipper2 polygon clipping and offsetting library

• Angus Johnson - Clipper2
• https://github.com/drlukeparry/pyclipr

And here is a 3D-library

• https://lukeparry.uk/pycork-a-boolean-csg-library-for-python/

[naveen521kk]

I understand that it could take long time for "in-house" solution and I am aware that the "blanket is always short", but IMO this could be a good MsC thesis work for some student. ;-)

It was me who added the dependency. I've implemented it as a proof of concept where we could do Boolean Operations on Mobjects and it ended up in the library as it is. Writing it "in-house" would be hard and would not be as performant as it is now (because you know, python). I recommend you create a new issue so we won't lose it.

[ubaldot]

@naveen521kk Oki. I will open a dedicated issue and I close this one.

[Ethan-yt]

after reinstall package [skia-pathops](https://github.com/fonttools/skia-pathops) the problem is fixed for me.