我知道,这是一个很晚的回复。但这是在 Google 搜索中名列前茅的线程,因此似乎是添加替代建议来处理此问题的地方,有些人可能会觉得有用。
您可以使用 SDL_WaitEvent 编写代码,这样,当您的应用程序没有积极地为任何东西设置动画时,它会阻塞并将 CPU 交还给操作系统。
但是您可以从另一个线程(例如游戏逻辑线程)向队列发送用户定义的消息,以使用该消息唤醒主渲染线程。然后它通过循环渲染一个帧,交换并再次返回到 SDL_WaitEvent。这些用户定义的消息中的另一个可以等待被拾取,告诉它再次循环。
这种结构可能适用于存在“爆发”动画的应用程序(或游戏),但除此之外,最好阻止它并使其空闲(并节省笔记本电脑的电池电量)。
例如,一个 GUI,当您打开或关闭或移动窗口或将鼠标悬停在按钮上时,它会显示动画,但大多数情况下它是静态内容。
(或者,对于一个游戏,虽然它在游戏中一直处于动画状态,但对于暂停屏幕或游戏菜单,它可能不需要这样做。因此,您可以在游戏期间发送“SDL_ANIMATEEVENT”用户定义的消息游戏,但随后,在游戏菜单和暂停屏幕中,只需等待鼠标/键盘事件并实际让 CPU 空闲和冷却。)
确实,您可以拥有自触发动画事件。因为渲染线程被“SDL_ANIMATEEVENT”唤醒,然后又完成了一帧动画。但是由于动画没有完成,渲染线程本身会向自己的队列发布一个“SDL_ANIMATEEVENT”,当它到达 SDL_WaitEvent 时会触发它再次唤醒。
还有一个想法是 SDL 事件也可以携带数据。因此,您可以在事件中提供“data1”中的动画 ID 和“data2”中的“当前帧”计数器。这样当线程接收到“SDL_ANIMATEEVENT”时,事件本身会告诉它要执行哪个动画以及我们当前在哪个帧上。
我觉得这是一个“两全其美”的解决方案。它的行为类似于 SDL_WaitEvent 或 SDL_PollEvent,由应用程序自行决定,只需向自身发送消息。
对于游戏来说,这可能不值得,因为您会不断更新帧,所以这并没有太大的优势,也许不值得费心(尽管即使是游戏也可以从 0% 的 CPU 使用率中受益)暂停屏幕或游戏内菜单,让 CPU 冷却并减少笔记本电脑电池的使用)。
但是对于像 GUI 这样的东西——它有更多的“burst-y”动画——然后鼠标事件可以触发一个动画(例如,打开一个新窗口,它会缩放或滑入视图)将“SDL_ANIMATEEVENT”发送回队列。它会一直这样做,直到动画完成,然后再次回到正常的 SDL_WaitEvent 行为。
这个想法可能适合某些人的需要,所以我想我会把它放在这里供一般消费。