SDL2 SDL_SetEventFilter VS SDL_WaitEvent

我有一個典型的SDL事件循環中調用SDL_WaitEvent，跑進熱烈討論的問題（見here和here）在我的應用程序無法調整大小時重新繪製，因爲SDL_WaitEvent不返回直到在某些平臺上完成調整大小（Win32 & Mac OS）。在每一次討論中，都提到了使用SDL_SetEventFilter來解決這個問題的技巧，並且或多或少被接受爲解決方案和黑客。SDL2 SDL_SetEventFilter VS SDL_WaitEvent

使用SDL_SetEventFilter方法完美地工作，但現在我正在查看我的代碼，並且實際上已將我的SDL_WaitEvent中的所有代碼移動到EventFilter中，並僅處理那裏的事件。

建築上它的魚腥味。

除了在單獨的線程上被調用的可能性之外，是否有任何問題與這種將消息分派給我的應用程序的方法由SDL_SetEventFilter設置？

獎勵問題：SDL如何在內部處理此問題？據我所知，這個調整大小的問題植根於底層平臺。例如，Win32將發出WM_SIZING，然後輸入自己的內部消息泵，直到發出WM_SIZE。什麼是觸發SDL EventFilter運行？

來源

2017-10-22 Wilfredo Velázquez-Rodríguez

什麼是違反SDL_PollEvent？而不是無限期地等待事件，只要輪詢他們每個週期（如果有的話）。 – skypjack

這沒有幫助。 SDL_PollEvent的行爲與SDL_WaitEvent的行爲完全相同，將會阻止，直到調整大小/移動完成 –

如果它解決了問題，我不會將它作爲註釋發佈，對吧？這只是一個偏離主題的建議。 – skypjack

經過更多實驗和篩選源代碼後回答我自己的問題。

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事件結束時對消息進行排隊並將它們交還給您。你立即把它們交給你，作爲泵送的一部分。

在我的架構中，這完全適合。因人而異。

來源

2017-10-26 20:57:02

SDL2 SDL_SetEventFilter VS SDL_WaitEvent

回答

相關問題