Q:

Managing Fonts, Brushes and Pens in MFC

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?)

A:

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.

A:

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.

