在 MFC 中管理字体、画笔和笔
我即将在 MFC 中启动一个文本呈现窗口。鉴于文本渲染窗口将允许不同样式的字体（并且每个窗口可以有不同的字体），我一直在考虑字体的管理。
创建某种字体管理器有意义吗？我在想，每次需要字体时，渲染器都会将所需的 LOGFONT 传递给管理器。如果CFont存在，则将其返回，如果不存在，则创建它。该字体管理器在系统中是全局的。
这是否太过分了？ Windows 是否在幕后做这种事情，这意味着从应用程序的角度来看这是完全没有必要的？
对于特定颜色的画笔和钢笔也可以这样说。创建后将它们存储在某种管理器中是否更快？例如，如果我创建一个实心淡紫色画笔，另一个需要淡紫色的窗口是否应该请求现有画笔？
另外，我猜测如果我将磁盘上的图像加载到 blit，如果两个单独的窗口从磁盘加载相同的图像，我将有两个图像 - 所以这些是缓存的良好候选者（也许通过文件名？）
I am about to start a text-rendering window in MFC. Given that the text-rendering window will allow fonts of differing style (and each window can have a different font), I've been thinking about the management of fonts.
Would it make sense to create some kind of a font manager? I was thinking that each time a font is required, the renderer would pass the desired LOGFONT to the manager. If a CFont existed, it would be returned and if not, created. This font manager would be global in the system.
Is this overkill? Does Windows do this kind of thing under-the-hood meaning it is totally un-necessary from an application perspective?
One could also say the same for brushes and pens of a particular colour. Is it faster to store them in a manager of some sort once one is created? E.g, if I create a solid mauve brush, should another window that wants mauve request the existing brush?
Also, I'm guessing that if I load an image on disk to blit, that if two separate windows load the same image from disk, I'll have two images - so these are good candidates to cache (by filename, perhaps?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不同的 Windows 版本对这些内容进行了不同数量的缓存。
我的建议取决于两件事：
不要过早优化。如果您发现将来可能需要优化，请继续并确保对其进行架构，以便从字体管理器检索字体。但是，在出现可证明的性能缺陷之前，不要费心实现缓存。
测量。制作一个测试用例程序，创建和销毁数百种不同样式的字体，并测量其性能扩展情况。
我曾经花了很长时间写一个多线程渲染器。结果发现，因为 GDI 驱动程序无论如何都会串行访问硬件，所以我得到的好处为零。
Different windows versions have done differing amounts of caching of these things.
My advice hinges on two things:
Don't optimize prematurely. If you can see a possible need to optimize in the future, go ahead and ensure that you architect it such that Fonts are retrieved from a font manager. But, until there is a provable performance deficit, don't bother implementing the cache.
Measure. Make a test case program that creates and destroys hundreds of differently styles fonts and measure how it scales in performance.
I once spent a long time writing a multi threaded renderer. Only to find that, because the GDI drivers serialize access to the hardware anyway, I got zero benefit.
对于字体来说，这是一个不错的策略，Windows 字体映射器并不便宜，而且典型程序使用的字体数量是有限的。但画笔和钢笔则不然，它们非常便宜，所以只需动态创建和销毁它们即可。
这一策略的最终背书来自于微软自己的代码，Winforms就是这么做的。请注意，缓存会产生一个新问题，当用户更改系统设置时，您必须使缓存失效。系统颜色、DPI 之类的东西。您必须在顶层窗口中监听 WM_SETTINGCHANGE。
This is an okay strategy for fonts, the Windows font mapper isn't that cheap and the number of fonts that a typical program uses is finite. But not for brushes and pens, they are dirt-cheap so just create and destroy them on the fly.
The ultimate endorsement for this strategy comes from Microsoft's own code, Winforms does this. Beware that caching creates a new problem, you have to invalidate the cache when the user changes system settings. System colors, DPI, that sort of thing. You have to listen for WM_SETTINGCHANGE in a toplevel window.
Windows 已经（自从我为 Windows 编程以来已经有一段时间了）有各种 GetStockXXX 函数，例如 GetStockFont()。我快速谷歌了一下，但没有找到明显的 MSDN 文档。
编辑：参见 GetStockObject(): http://msdn. microsoft.com/en-us/library/dd144925%28VS.85%29.aspx
Windows has/had (it's been a while since I programmed for Windows) had various GetStockXXX functions, such as GetStockFont(). I had a quick Google but no obvious MSDN docs came up.
Edit: see GetStockObject(): http://msdn.microsoft.com/en-us/library/dd144925%28VS.85%29.aspx