我突然想到一个新法子，GMS 1.3 版本中加入的新的内置变量：Application Surface
这样就不用Create from Surface ，直接暂停Application Surface的绘制交换链，同时解散相关的OBJ。。
参考：http://docs.yoyogames.com/source/dadiospice/002_reference/surfaces/the%20application%20surface.html
你可以简单的理解这个表面就是：GMS绘制事件中所调用的表面（画布），也就是默认的所有Draw 操作都绘制在这个表面上。
每一步先 Draw_clear() 然后绘制这个表面，呈现游戏画面。现在， 我们暂停游戏只需取消 Draw_clear() ，同时解散相关OBJ。
为什么？因为OBJ都解散了，不存在Draw操作，不会对这个系统表面进行图画，同时系统表面并没有被Clear.我们就一直绘制这个表面即可。
要恢复的时候，激活OBJ，并继续Draw_clear()操作。
在哪里绘制这个表面？在Draw GUI 事件中 Draw_surface();
在哪里 Clear Application Surface？在 Draw_start事件中 Draw_clear() , Application Surface 就是默认的系统画布，直接用相关的Draw函数;

哦，忘了一点，还需要预先调用application_surface_draw_enable(flag);
FLAG填写False，使得GMS不会自动处理绘制。

这变量还没细读，不过喵的理解，因为Application Surface相当于所有draw事件的绘制表面，所以通过解散并暂停这个表面的绘制确实可以实现暂停效果，不过估计会没有机会只暂停一部分的游戏内容（比如暂停背景的游戏画面，而前景的按钮什么的仍然可以活动并操作等等啦）
相比之下喵还是比较喜欢传统的view_surface_id做暂停的效果，因为可以针对view单独获取draw画面，所以相当容易控制…… 唔唯一不好的地方就是必需要强行使用view。
不过Application Surface用作画面处理确实蛮赞的~

不过估计会没有机会只暂停一部分的游戏内容（比如暂停背景的游戏画面，而前景的按钮什么的仍然可以活动并操作等等啦）
关于这个问题，是不可能出现的，在2L中，我已经补充了一个前提函数，终止GMS对这个表面的自动处理，然后再开发者使用函数手动清除。最后结合1L中的参考，可知事件的先后顺序。显然，我们的结果是完整的。

我的思路，来至于官方技术博文：Optimising The Draw Pipeline
可能是作者故意没有写绘制 Application Surface 之后进行一次清除，在理解了这个变量的意义后，对博文源码中Object0添加Draw_Start事件，并加入Draw_clear();实现手动清除一次表面。
https://www.yoyogames.com/tech_blog/61

LZ凹凸吗？
这方法真不错！

利用Application Surface，gms1.3或者EA版
详细的解说，之后再发文章
[无效] http://pan.baidu.com/s/1kTp47vL

发现，Application Surface的绘制，还受到当前ROOM相关的参数的影响，导致不能正常“显示”（已解决）。