GRAPHIC FONT in PB9

[Laurence Jackson]

From the PB/Win9 help file:

GRAPHIC FONT has been superceded by the GRAPHIC SET FONT statement, although GRAPHIC FONT remains supported for a limited period. Existing code should be converted to the new syntax as soon as possible.

Another reason for converting to the new syntax is that PB9 seems to create a new instance of the font on each use, whereas PB8 didn't. I was using GRAPHIC FONT repeatedly in a program (about 5 times a second) and ran into problems after about 20 minutes of execution. No problem at all with GRAPHIC SET FONT.

[Philip Zeller]

Same problem here

You know, I wish I would have seen this post sooner! I've been banging my head against a wall on a program which used GRAPHIC FONT in a loop. Worked in PB8, eventually ran into problems on PB9. The entire graphic control suddenly [appeared] to be a direct descendant of the desktop (very odd).

Your explanation makes perfect sense.

The documentation should probably be amended to mention this anomaly, since GRAPHIC FONT is still [meant] to be supported in PB9.

It's always tricky to leave in legacy support for commands between versions, but in this case, at least when fonts are used within a loop, we must change between GRAPHIC FONT and FONT NEW/GRAPHIC SET FONT methods if we switch between PB8 and PB9 reliably (in other words, neither one method is 100% reliable and works in both PB8 and PB9, a bummer if you want to switch back/forth).

[Chris Boss]

Resources in Windows (ie. Brushes, Fonts, etc.) must be used as sparingly as possible. Of course you can use a number of individual instances of any resource, but Windows does have internal limits (not defined in Docs).

If too many resources are created at one time, you can literally bring Windows to "its knees" (crash it). When this occurs very strange things will happen to all apps running and the desktop. Fonts and colors may not appear right and eventually Windows will crash or lock up.

One approach (which is what I use with both Fonts and Brushes) is to create a universal list of colors/fonts your app will use and then use those handles for times you require them (ie. multiple controls can be sent the WM_SETFONT message using the same font handle).

In the case when the number of unique brushes or fonts is unlimited (meaning only a limited number used at one time, but they can keep changing and the new ones replace them), you have to destroy the resources after their use as soon as possible.

If you write loop code than runs a significant number of iterations and in every new iteration a new brush or font is created, but not deleted immediately after it is used, then the total number of instances of brushes or fonts can become quite large and this will make Windows unstable at some point.

I don't know how the DDT font commands work under the hood, but if you create too many multiple instances of them it can cause serious problems.

DDT provides the FONT END command which should be used when the font is no longer needed. Make sure you delete fonts when no longer needed. Especially in loop code you should use FONT NEW and a matching FONT END so after the iteration no font exists.

[Philip Zeller]

Good point

Clearly, based upon the behavior of the "GRAPHIC FONT" command in PB8, it is "under the hood" either re-using, or auto-destroying the fonts created (otherwise, graphic font would crash in an inner-loop in PB8 as well, having eventually exhausted the resources).

The PB9 (DDT) approach is superior anyway, we clearly create a font using FONT NEW, then apply that font using GRAPHIC SET FONT. Why create a dozen of the same font to use in a dozen graphics, after all.

It's probably how the graphic font selections should have been implemented in the DDT of PB8 originally. In all honesty, I always did think it a bit odd the way GRAPHIC FONT worked in PB8. I'm glad to see the change, as it makes no sense to create a new font every time you want to apply a font using DDT.

I'm just suggesting that a change in how GRAPHIC FONT works (or fails to work) should probably have been specifically documented, for the sole reason that it will break code of those expecting it to be cleaning up/consolidating the use of the resources in the same manner as it did before in PB8. Alternately, just drop support for GRAPHIC FONT.

Incidentally, a benchmark shows that the new approach is (very marginally) faster. No surprise there.

BTW, Chris, I use the same approach with %WM_SETFONT of creating all of my fonts at the top of my code, then applying as needed. It's just cleaner and more efficient this way.

[Chris Boss]

In my DDT tools I use a routine which uses a technique which does Font Pooling. Rather than recreate the same font over and over again, when a font is created, it is saved in a font pool. When ever that same font is created again, rather than create a new instance, it is retrieved from the font pool.

If you don't want to destroy and recreate the exact same font over and over again, then some sort of font pooling can be used to minimize waste of fonts.