由于本人美工爆炸，所以每次做游戏很少用sprite(有也是网上下的)，而是用draw_circle，draw_rectangle，draw_line之类的draw形状的函数来绘制简易图像。最近开了个新坑，发现用这些矩形组合起来有一些比较cooooool的效果，于是全程所有地方都是直接draw形状的。
但是出现了问题，就是这些draw形状的函数似乎多起来之后对显示芯片的压力很大？60的房间速度，在同学稍差的电脑上最多58fps。改装安卓之后就是20-40fps徘徊了。我制作过程中曾写错一个地方，导致某种砖块绘制量翻倍，这倒好，游戏运行3-5帧后直接报错，说顶点缓存溢出(vertex buffer overflow)，后面还加上了超过了多少KB。这是怎么个情况？
我原以为draw形状的函数比draw_sprite效率高，因为直觉上认为那些简单形状是比一个精灵要容易呈现的，但事实并非如此？
有没有哪位大佬能解释一下，或者讨论一下？

可以开一下debug overlay，看看顶点批处理次数

现在出现了一个很有趣的问题。
空房间+一个obj，obj仅有draw代码画1000个形状。先是用gm8测试，1000条直线、1000个矩形、1000个圆，均能保持200-300fps；而当用gms测试时，1000条直线也能有300多fps，但是换成1000个矩形的时候，报如下错误：
-无法创建顶点缓存。

实际上300多fps已经足够，这已经是1000个形状了，实际上我的游戏里一个房间并没有画1000个形状，甚至200都不到，这就很奇怪，怀疑是自己代码的问题？
开启debug_overlay后，发现Step事件耗时很短，而Draw事件耗时很长，在安卓机上还有一条很长的白色条，F1中说明是等待GPU返回的时间？在Windows上就几乎没有这一段白色的。所以我初步认为这个白色条消耗的时间与我代码无关，所以关键在Draw事件。
查看F1关于Draw Event的说明，其中提到Draw时间特定性很强，应尽量只包含实际上绘制的代码而不要包含进行高消耗运算的代码。于是我便检查每个Object的Draw事件代码，事实上并没有什么高消耗的运算代码，出了绘制函数意外都是一些与绘图直接相关的，例如根据变量计算alpha，长度等。而且因为前文1000次绘制实验也采用了随机函数，所以不应该是随机函数的消耗，难道是少量几个distance_to_object？有可能，因为毕竟涉及到mask和碰撞的计算。

但我的问题在于，就算我把这些疑似高消耗的函数挪到Step事件，那Draw事件原来同一函数消耗的时间转移到Step事件中，总的完整一帧消耗的时间不应该还是一样吗？还是我的理解有误，Step事件中执行效率比Draw事件中高？
经过我在做这些实验之前的一番优化之后（像令View之外的instance不绘制之类的），在一般windows电脑上帧率倒是能保持60，开个QQ屏幕分享保持58-59，平均帧率有一定提高。但在我自己小米4上实在是掉帧太严重，同学一些比较新的手机倒是还行。
所以想请教一下各位懂的人，把那些疑似高消耗的函数从Draw移到Step中能否解决问题？

可能是绘制形状的问题吧，那为啥不试试直接绘制sprite呢
另外debugger的profile完全可以让你知道哪部分消耗时间多啊，包括绘制事件