關于設備上下文(Device Context, 簡稱 DC) ，我想到這樣一個原則：大多數(shù)情況下，窗口 DC 只是作為臨時使用。

例如，如果你想在窗口中繪制些什么東西，你可以在 WM_PAINT 消息到來的時候，調用 BeginPaint，或者在其他時間點，調用 GetDC，但我們通常還是建議將繪制工作盡可能地放在 WM_PAINT 消息處理代碼中。

當你調用上面說的兩個函數(shù)后，窗口管理器會產(chǎn)生一個窗口對應的 DC 并返回給你。然后，你可以使用這個 DC 進行繪制，當繪制結束的時候，通過調用 EndPaint 或者 ReleaseDC，我們將 DC 恢復它原本的狀態(tài)并返回給窗口管理器。

從內部實現(xiàn)的角度來看，窗口管理器保留了一小段 DC 緩存，當人們請求窗口 DC 時，它會讀取該緩存，當 DC 返回時，它會返回到緩存中。由于窗口 DC 只是臨時使用的，因此未完成使用的 DC 的數(shù)量通常不是很多，并且小型緩存足以滿足正常運行系統(tǒng)中的 DC 需求。

如果注冊窗口類并在類樣式中包含 CS_OWNDC 標志，則窗口管理器將為窗口創(chuàng)建一個 DC，并使用特殊標記將其放入 DC 緩存中，該標記表示: “不要從 DC 緩存中清除此 DC，因為它是此窗口的 CS_OWNDC “。如果調用 BeginPaint 或 GetDC 來獲取CS_OWNDC窗口的 DC，則始終會找到并返回該 DC（因為它被標記為“從不清除”）。這樣做的后果有好有壞。

好的一方面是：由于 DC 是專門為窗口創(chuàng)建的并且永遠不會被清除，因此你不必擔心在將其返回到緩存之前會被清理掉。每當你調用 BeginPaint 或 GetDC 以獲取CS_OWNDC窗口時，你總是會得到那個特殊的 DC。事實上，這就是 CS_OWNDC 窗口的全部意義：你可以創(chuàng)建一個 CS_OWNDC 窗口，獲取其 DC，按照你喜歡的方式進行設置（選擇字體、設置顏色等），即使你釋放 DC 并稍后再次獲取它，你也會得到相同的 DC，它將是你離開它的方式。

壞的一方面是：你正在獲取本來應該暫時使用的東西（窗口 DC）并永久使用它。早期版本的 Windows 對 DC 的限制非常低（八個左右），因此在不需要 DC 時立即釋放它們至關重要。自那時以來，這一限額已大幅提高，但基本原則仍然是：應該小心謹慎的使用 DC 并盡可能早地歸還給窗口管理器。你可能已經(jīng)注意到，CS_OWNDC 的實現(xiàn)仍然使用 DC 緩存，只是這些 DC 有一個特殊的標記，所以 DC 管理器知道要特別對待它們。這意味著大量 CS_OWNDC DC 最終會”污染” DC 緩存，從而減慢未來對需要搜索 DC 緩存的函數(shù)（如 BeginPaint 和 ReleaseDC）的調用。

（為什么DC 管理器不優(yōu)化處理大量 CS_OWNDC DC 的情況？首先，正如我已經(jīng)指出的，最初的 DC 管理器不必擔心大量 DC 的情況，因為系統(tǒng)一開始甚至無法創(chuàng)建那么多 DC。其次，即使在提高了對 DC 數(shù)量的限制之后，重寫 DC 管理器以優(yōu)化 CS_OWNDC DC 的處理也沒有多大意義，因為程序員已經(jīng)被告知要謹慎使用 CS_OWNDC 。這是軟件工程的實用性之一：你只能做這么多。你決定做的一切都是以犧牲其他東西為代價的。很難證明優(yōu)化程序員被告知要避免的場景是合理的，而事實上他們已經(jīng)在避免這種情況。你不會針對有人濫用你的系統(tǒng)的情況進行優(yōu)化。這就像，花時間設計汽車的發(fā)動機，以便在汽車沒有機油的情況下保持良好的油耗。）

更糟糕的是，大多數(shù)窗口框架庫和幾乎所有示例代碼都假定你的窗口不是 CS_OWNDC 窗口。
請考慮以下代碼，該代碼以兩種字體繪制文本，使用第一種字體來指定字符在第二種字體中的位置。它看起來很好，不是嗎？

我們得到兩個用于窗口的 DC。首先，我們選擇第一種字體;在第二個中，我們選擇第二個。在第一個 DC 中，我們還將文本對齊方式設置為 TA_UPDATECP 這意味著傳遞給 TextOut 函數(shù)的坐標將被忽略。相反，文本將從“當前位置”開始繪制，“當前位置”將更新到字符串的末尾，以便對 TextOut 的下一次調用將從上一個調用中斷的地方繼續(xù)。

設置兩個 DC 后，我們一次繪制一個字符的字符串。我們在第一個 DC 中查詢當前位置，并以相同的 x 坐標（但略低）繪制第二種字體中的字符，然后以第一種字體繪制字符（這也推進當前位置）。

文本繪制循環(huán)完成后，我們將還原兩個 DC 的狀態(tài)，作為標準繪制流程的一部分。
該函數(shù)的目的是繪制類似這樣的內容，其中第一個字體大于第二個字體。

如果窗口沒有設置 CS_OWNDC，則結果就是你想要的了。你可以通過從我們的臨時程序中調用它。

但是，如果窗口設置了 CS_OWNDC，那么壞事就會發(fā)生。你可以將 wc.style = 0 修改成 wc.style = CS_OWNDC，你就會看到這樣的效果:

當然，如果你了解 CS_OWNDC 的工作原理，這根本不出乎意料。理解的關鍵是：當窗口設置了 CS_OWNDC 時，無論你調用多少次，GetDC 都會返回相同的 DC?，F(xiàn)在你所要做的就是查看 FunnyDraw 函數(shù)，并記住 hdc1 和 hdc2 實際上是一回事。

到目前為止，函數(shù)的執(zhí)行是很正常的。

HDC hdc2 = GetDC(hwnd);

由于該窗口是 CS_OWNDC 窗口，因此在 hdc2 中返回的 DC 與在 hdc1 中返回的 DC 相同。換句話說，hdc1 == hdc2！現(xiàn)在事情變得令人興奮了。

HFONT hfPrev2 = SelectFont(hdc2, hf2);

由于 hdc1 == hdc2，這真正做的是從 DC 中取消選擇字體 hf1 并選擇字體 hf2。

現(xiàn)在這個循環(huán)完全崩潰了。在第一次迭代中，我們從 DC 檢索當前位置，它返回 （0， 0），因為我們還沒有移動它。然后，我們將位置 （0， 30） 處的字母“H”繪制到第二個 DC 中。但由于第二個 DC 與第一個 DC 相同，因此真正發(fā)生的是我們將 TextOut 調用到處于 TA_UPDATECP 模式的 DC。因此，坐標被忽略，顯示字母“H”（以第二種字體），并將當前位置更新為“H”之后。最后，我們將“H”繪制到第一個 DC（與第二個相同）。我們認為我們用第一種字體繪制它，但實際上我們用第二種字體繪制。我們認為我們在 （0， 0） 處繪制，但實際上我們在 （x， 0） 處繪制，其中 x 是字母“H”的寬度，因為對 TextOut（hdc2， …） 的調用更新了當前位置。

因此，每次通過循環(huán)時，字符串中的下一個字符都會顯示兩次，全部以第二種字體顯示。

但是等等，災難還沒有結束。看看我們的清理代碼：

SelectFont(hdc1, hfPrev1);

這會將原始字體還原到 DC 中。

SelectFont（hdc2， hfPrev2）;

這將重新選擇第一個字體！我們未能將 DC 還原到其原始狀態(tài)，最終將“損壞”的 DC 放入緩存中。

這就是為什么我將 CS_OWNDC 描述為“更糟”。它采用過去有效的代碼，并通過違反大多數(shù)人對 DC 做出的假設（通常沒有意識到）來破壞它。

如果你覺得 CS_OWNDC 很糟糕了，沒事，還有更糟的，下次我會談談被稱為 CS_CLASSDC 的災難。

總結

對于自己不了解的東西，要小心謹慎的嘗試，決不能先入為主。
像一個嬰兒一樣對待所有新生事物，正所謂：一葉障目也。