SDL2 SDL_SetEventFilter vs SDL_WaitEvent

Question

我有一个典型的SDL事件循环调用SDL_WaitEvent，并遇到了一个备受讨论的问题(参见这里和这里)，在这个问题上，我的应用程序在调整大小时无法重新绘制，因为在某些平台(Win32 & Mac )上，SDL_WaitEvent不会返回。在每一次讨论中，都提到了使用SDL_SetEventFilter绕过它的技术，并或多或少地将其作为解决方案和黑客来接受。

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

在建筑上它是可疑的。

除了在一个单独的线程上被调用之外，这种在SDL_SetEventFilter设置的函数中向我的应用程序发送消息的方法有什么缺点吗？

附加问题: SDL如何在内部处理这个问题？据我所知，这个调整大小的问题植根于底层平台。例如，Win32将发出一个WM_SIZING，然后输入它自己的内部消息泵，直到WM_SIZE发布。是什么触发SDL EventFilter运行？

Answer 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