C++ 在MFC中管理字体、画笔和笔

我将在MFC中启动一个文本渲染窗口。考虑到文本呈现窗口将允许使用不同样式的字体（每个窗口可以有不同的字体），我一直在考虑字体的管理

创建某种字体管理器有意义吗？我认为每次需要字体时，渲染器都会将所需的

LOGFONT

传递给管理器。如果存在一个

CFont

，则将返回它，如果不存在，则创建它。此字体管理器在系统中是全局的

这是不是太过分了？Windows是否暗中做了这类事情，这意味着从应用程序的角度来看，它是完全不必要的

对于特定颜色的刷子和钢笔也可以这样说。一旦创建了管理器，将它们存储在某种管理器中是否会更快？例如，如果我创建了一个纯色的淡紫色笔刷，另一个想要淡紫色的窗口是否应该请求现有的笔刷

另外，我猜测，如果我在磁盘上加载一个映像到blit，如果两个单独的窗口从磁盘加载同一映像，我将有两个映像-因此，这些都是很好的缓存候选对象（可能是通过文件名？

windows已经/曾经（我为windows编程已经有一段时间了）具有各种GetStockXXX函数，例如GetStockFont（）。我用谷歌快速搜索了一下，但没有明显的MSDN文档出现

---

编辑：请参见GetStockObject（）：

不同的windows版本对这些内容进行了不同数量的缓存

我的建议取决于两件事：

不要过早地优化。如果您认为将来可能需要进行优化，请继续并确保您对其进行了设计，以便从字体管理器中检索字体。但是，在出现可证明的性能缺陷之前，不要费心实现缓存

量。制作一个测试用例程序，创建和销毁数百种不同样式的字体，并测量其性能的伸缩性

---

我曾经花了很长时间编写多线程渲染器。结果发现，由于GDI驱动程序序列化了对硬件的访问，我没有得到任何好处。

这是一个不错的字体策略，Windows字体映射器没有那么便宜，典型程序使用的字体数量是有限的。但不是刷子和钢笔，它们非常便宜，所以只要在飞行中创建和销毁它们就可以了

---

这一策略的最终认可来自微软自己的代码，Winforms就是这样做的。请注意，缓存会产生新问题，当用户更改系统设置时，必须使缓存无效。系统颜色，DPI，诸如此类的东西。您必须在顶层窗口中收听WM_设置更改。

嗨，詹姆斯，是的，我知道GetStockXXX函数。但是，这仅适用于库存对象（基本字体和画笔），而不是自定义颜色或用户从字体选择对话框中选择的字体（以及随后应用于该字体的任何样式，如粗体、斜体和下划线）。