LOCAL: Not enough space in GDI heap
Cenedese at indel.ch
Thu Feb 12 10:28:32 CST 2004
>>I suspect your leak happens in the olefont implementation. You want
>>to check that each hfont is destroyed when the IOleFont interface is
>When are the fonts released? If a control creates a font and uses it until
>the dialog gets closed it doesn't help much. There will still be too many
>fonts while running. Or should the control create a font every time it has
>to draw anything and will release it again after? I can see releases but
>the reference counter never reaches 0 until the end of the program where
>all remaining fonts are cleaned up.
I didn't really get further. Everything looks normal if these assumptions and
observations are correct:
- The freetype engine will cache every font for every different handle.
- And as CreateFontIndirect returns a different handle on every call the engine
will also cache as many fonts (if they are used).
- The VB runtime will create a font for every control as they can be different.
(At least it looks like that with dozens of calls to CreateFontIndirect and
therefore many different font handles).
- A font will only get deleted from cache if the program does so, not from
- As there is no error in the end about references not being 0 or so I guess
that every GetObject also has a matching ReleaseObject. But the timing
may be different to windows. (Tested with a simple app which works ok
but still uses as many fonts as there are controls even if all are the same).
Is there a possibility to increase the GDI heap? Like that I could at least
test if the app works ok besides this font problem. I ran it again on Windows
and looked at the resources. It only uses 40 fonts while running, but I
don't know about the startup. Comparing this to the wine stats it seems
that Windows can use the same fonts for different controls. Or it does
release and reallocate them on demand.
So I'm out of powder again. If anybody wants to test it I can send the
More information about the wine-devel