SDL2 SDL_SetEventFilter 与 SDL_WaitEvent答案

【问题标题】：SDL2 SDL_SetEventFilter vs SDL_WaitEventSDL2 SDL_SetEventFilter 与 SDL_WaitEvent
【发布时间】：2017-10-27 04:57:02
【问题描述】：

我有一个典型的 SDL 事件循环调用 SDL_WaitEvent，并遇到了一个备受争议的问题（请参阅 here 和 here），我的应用程序在调整大小期间无法重新绘制，因为 SDL_WaitEvent在某些平台（Win32 和 Mac OS）上完成调整大小之前不会返回。在每个讨论中，都提到了使用SDL_SetEventFilter 绕过它的技术，并且或多或少地被接受为一种解决方案和一种技巧。

使用SDL_SetEventFilter 方法效果很好，但现在我正在查看我的代码，实际上我已经将所有代码从SDL_WaitEvent 移到了我的EventFilter 中并在那里处理事件。

从架构上讲，它很可疑。

除了可能在单独的线程上调用之外，在SDL_SetEventFilter 设置的函数中向我的应用程序发送消息的这种方法是否有任何问题？

额外问题：SDL 如何在内部处理此问题？据我了解，这个调整大小问题根源于底层平台。例如，Win32 将发出 WM_SIZING，然后进入自己的内部消息泵，直到发出 WM_SIZE。是什么触发了 SDL EventFilter 运行？

【问题讨论】：

SDL_PollEvent 反对什么？与其无限期地等待事件，不如在每个周期轮询它们（如果有）。
这没有帮助。 SDL_PollEvent 的行为与 SDL_WaitEvent 完全相同，并且会阻塞直到调整大小/移动完成
如果它解决了问题，我不会将其作为评论发布，对吧？这只是一个离题的建议。
那我不知道你想让我回答什么。我没有使用 SDL_PollEvent 因为我不需要超时。我会通过轮询而不是等待来浪费不必要的周期。

标签： sdl sdl-2

【解决方案1】：

经过更多实验并筛选源代码后回答我自己的问题。

SDL 处理事件的方式是，当您调用SDL_WaitEvent/SDL_PeekEvent/SDL_PeepEvents 时，它会泵送 win32 直到没有消息为止。在该泵送期间，它将处理 win32 消息并将它们转换为 SDL 事件，并对其进行排队，以便在泵送完成后返回。

win32 处理移动/调整大小操作的方式是进入消息泵，直到移动/调整大小完成。这是一个常规的消息泵，因此在此期间仍会调用您的 WndProc。你会收到一个WM_ENTERSIZEMOVE，然后是许多WM_SIZING 或WM_MOVING 消息，最后是WM_EXITSIZEMOVE。

这两件事一起意味着当您调用任何 SDL 事件函数并且 win32 执行移动/调整大小操作时，您将被卡住，直到拖动完成。

EventFilter 解决这个问题的方法是它作为 WndProc 本身的一部分被调用。这意味着您不需要将消息排队并在 SDL_Peek/Wait/Peep 事件结束时将它们交还给您。作为抽水的一部分，您会立即将它们交给您。

在我的架构中，这非常适合。 YMMV。

【讨论】：