2DTools does not work on MacBook M1/Ventura

I do very much like to use TIG’s 2DTools, only not all tools work.



  • 1st click and start creating the first line;
  • It is possible to 2nd click to set the endpoint and start making the second line;
  • Beachball appears and keeps spinning infinitely;
  • Can only be stopped by SU forced termination;
  • After termination, OS asks Apple to send a notification to Apple, and restart SU;
  • SU asks to send a Bug Splat. Did.


  • While selecting the button, the beachball appears immediately;
  • Can only be stopped by forcibly terminating SU;
  • After termination, OS asks Apple to send a notification to Apple, and restart SU;
  • No request from SU to send a Bug Splat.


  • Similar to Rectangle. Only no request from SU to send a Bug Splat.


  • After clicking the starting point of the circle, the beachball is turning infinitely;
  • Only stop by SU forced termination;
  • After termination, OS asks Apple to send a notification to Apple, and restart SU;
  • No request from SU to send a Bug Splat.

Polyline edit

  • After selecting a point, the beach ball appears infinitely;
  • Can only be stopped by SU forced termination;
  • No request from OS Apple to send a report;
  • No request from SU to send a Bug Splat.

The tools below work well:

  • Set Z-plane
  • Line
  • Hatching
  • Fillet
  • Adjust
  • Line Style
  • Text

My setup looks like this
MacBook Pro 16-inch, 2021
Chip: Apple M1 Pro
Memory: 16 MB
macOS: Ventura 13.3.1
SketchUp Pro 2023 23.0.396

I now understand that on Windows PCs and other macOS versions, there are no problems with 2DTools, but that it focuses on Ventura 13.3.1.

@colin Do you know more about this issue? Can you see what options are available to look into this?

Thanks in advance for your efforts.

I don’t know his 2D tools at all. It looks like they haven’t been updated since before M1 existed, are you using them by running SketchUp in Rosetta?

@TIG may know more.

You should also post this over on SketchUcation, which is where TIG provides most of his extensions and is more likely to see it.

Edit: On a Mac, when an app is aborted the OS offers to send a report to Apple. Much of the time an abort is triggered by a known but unrecoverable error in the OS, such as a fatal error in a graphics driver, and Apple wants to know about such. But a manual force quit also generates an abort and gets the same handling. I usually tell macOS not to bother reporting an abort I know happened because I chose force quit - Apple won’t learn anything of value from the report.

1 Like

No Colin, I do not use Rosetta. macOS Ventura indicates that SU 2023 is a fully ‘universal’ applications. In that situation, Rosetta is not needed, is it?

Thx Steve. TIG is already aware of this issue.

As for passing on the error messages to Apple; you have a good point there. Makes little sense in that case :slight_smile:

The extension itself may be taking advantage of something pre M1 that isn’t there.
Or more likely , something had changed in a recent OS update that has caused the extension to not work

The common theme to these issues in multiple input points in a tool - e.g. when drawing a 3-point rectangle
The first two points are OK, but after that the beach-ball-of-death starts…
These tools work fine in other MAC OS versions and on all PCs, so something must be different with particular MAC OS !?
I don’t have a MAC with this OS/version to test with, so if anyone else wants to mess on with the coding, then feel free…
The RB files in the subfolder are not encrypted, so you can see what they are doing, and try your own edits etc…
I would like to get to the bottom of this, as I have another [confidential] commercial toolset that’s failing on these newer MACs, with input point issues that are very similar… On other MACs or PCs there’s no issues.

I reproduced the issue on macOS Ventura 13.3.1 on my Intel-based 2019 MBP 16" using both SketchUp 2023.0.396 and SketchUp 2022.1.165. So it is not specific to Apple Silicon nor to SketchUp 2023. I don’t have a pre-Ventura version of macOS running, so I can’t verify whether the issue also happens on Monterey or earlier.

After some testing, I found that the extension was looping in the draw (view) method after the second point is picked (in the @state > 1 clause.) I think the problem is that the code calls view.invalidate from within the draw method, triggering an immediate call again to draw - endless loop! I commented out the view.invalidate, and the problem went away.

I’m not clear why the view.invalidate was needed in the first place, even on Windows. @TIG, perhaps you can explain? If it is needed on Windows or older versions of macOS, a simple branch test based on OS version could fix it?

Edit: I posted this also on SketchUcation and TIG replied there. He is on the case!


An excellent example of good troubleshooting and debugging.

It is interesting that the bug has not been reported as occurring on Windows.
Perhaps there is a difference with the Ruby build for Mac ?

I would suggest that this is good candidate for an API Issue in the GitHib tracker.

Purely a guess, but I wonder if there is a difference in how events are queued on the two platforms, somewhat like how webdialogs were asynchronous on Mac but not on Windows.

I’ve had SketchUp running in Xcode all day, and been looking at this. I could see that it was getting stuck on the second draw_polyline, and I had noticed the invalidate line (and wondered about that).

Deleting that line does make the tool work.

Curious that it doesn’t affect older macOS, if that is the case.

I have an updated version now available for testing…


This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.