上一次,我們可以獲取到圖片動畫幀之間的時間間隔,如果想讓動畫轉起來,就必須有時鐘。插入的圖片動畫數量可能會比較多,因此要想不影響性能,時鐘必須很輕量級而且要很高效。
Windows平臺上實現時鐘的方式五花八門,你可以使用窗口相關的SetTimer來設置一個時鐘,也可以自己開辟線程來做等待觸發模擬時鐘,而Chromium封裝的要更加C++對象化一些:依托Windows窗口消息,抽象出延遲任務的概念。這種手法幾年前我也曾經考慮過,只是對其中下次最短觸發時間計算以及更新的算法和設計都有力不從心,最終得出的是誤差很大的精簡版:選擇固定的最小時間片為最小觸發單位,對很小的時間間隔誤差很明顯。
Windows有Timer Queues用來實現高效的異步時鐘,比較奇怪的是這組API用的貌似并不多。我們知道每個進程都有一個默認的線程池,可以在其中執行一些Work Items,時鐘隊列和等待操作也都會用到這個線程池。timer-queue中的timers創建和銷毀都很輕量高效,因此我選擇了它。
每個OLE圖片對象在設置圖片之后,如果發現是多幀的,就需要啟動動畫,創建時鐘:
WaitOrTimerCallback,
callback_parameter_.get(),
image_->GetFrameDelay(current_frame_),
0, WT_EXECUTEDEFAULT));
這里timer_是返回值,返回新建的時鐘對象,可以在OLE對象銷毀或者回調函數中進行刪除,而刪除操作會等待回調執行完畢才返回。傳遞TimerQueue為NULL表示使用系統的隊列。Period為0表示只觸發一次,觸發時間為image_->GetFrameDelay(current_frame_)。由于回調函數WaitOrTimerCallback是在線程池的線程中執行,所以更新操作需要同步到動畫圖片的創建線程中。callback_parameter_包含有上一節提及的ThreadState對象以及動畫OLE對象指針,ThreadState創建的時候會同時創建一個隱藏窗口用于工作者線程向UI線程同步操作:
BOOLEAN TimerOrWaitFired) {
ATLASSERT(TimerOrWaitFired == TRUE);
IMRichPicture::CallbackParameter* parameter =
reinterpret_cast<IMRichPicture::CallbackParameter*>(lpParameter);
ATLASSERT(parameter);
parameter->thread_state->UpdatePictureFrame(parameter->picture);
}
下面是UpdatePictureFrame的實現:
PostMessage(message_window_, kMessageUpdatePictureFrame,
reinterpret_cast<WPARAM>(picture->richedit()),
reinterpret_cast<LPARAM>(picture));
}
這樣繞一大圈子,是為了利用Timer Queues的同時保證圖片的更新操作是在UI線程中執行,因為圖片被插入也是發生在UI線程,即動畫控件創建于UI線程,為了避免加鎖帶來的麻煩以及死鎖的可能性,不應該輕易去加鎖,盡量利用操作系統提供的基礎設施來實現。這里需要注意的是隱藏窗口接收到kMessageUpdatePictureFrame消息時,richedit窗口可能已不存在或者動畫控件已經銷毀,因此使用指針前,需要判斷對象是否還存在:
IMRichEditImpl* richedit = reinterpret_cast<IMRichEditImpl*>(wparam);
IMRichPicture* picture = reinterpret_cast<IMRichPicture*>(lparam);
if (IMThreadState::current()->HasRichEdit(richedit))
richedit->OnUpdatePictureFrame(picture);
return 0;
}