据我所知，GMS的动作有比较严格的执行顺序，不太可能允许多线程。甚至有些制作人连不同instance执行同一个动作的先后顺序都要抠明白（话说验证结果似乎是各代版本的答案有差异）。据说有些插件能实现多线程效果，如果你能接受“有一部分执行过程不受自己控制”、“未来移植困难”、“出了问题可以寻求帮助的范围缩小”、“插件不好找”、“可能不适用于自己制作的内容”这些问题的话，可以试试看。
如果题主的核心需求是“解决大量计算的卡顿问题”，而不是前进了一步的“怎样开启多线程”，咱还是有一个可能的解决方案的，那就是启用shader，把计算内容从CPU转移到GPU。这个方案需要几个前提：
0、计算可以拆分至并行进行，而不是必须递推或更复杂的（比如递归）；
1、计算是直接进行，不需要过多复杂的逻辑判定；
2、计算结果同样是分布存储的，或者说可以和“图片”这种形式进行对应，而不是“汇总到一个结果”；
3、机器上有可以做这件事的GPU……你用4090啊，那没事了；

看你贴那么多代码，心痒痒。
图一：GML部分

图二：shader的fsh部分（在图1的197行开启）

来回改的时候留了一些debug的、替换下去没删除的代码，还注释着，反正凑合能看。
行184-203，对比表面sf[sf[0]]每个像素和y-1像素的差异，并把加权结果放到临时表面0上，其中加权算法在shader里边；
行204-228，将每行的差异记录累计到最左侧的那一列像素上；
行229-251，把结果导出到buffer，并根据差异情况决定是否标记为“分割”（ysp[]）；
咱做的那个拼图，可以用这个算法来进行辅助切割，虽说切割结果和实际还是有差异，不过大多数判定还是能用的。
顺便就是如果用cpu读所有像素的颜色（单线程），会慢很多。如果不借助buffer而是直接从表面读的话，差不多就是可以考虑放弃这个功能不做的程度。

某天见到这种，行列对齐的打乱图片，感觉当拼图玩还不错。不过，有些图片的打乱过程让格子的大小有差别，用参数重新切割和图片对不上，手工一个一个切又太麻烦了，就可以用这个算法来辅助判定。