LOCAL: Not enough space in GDI heap

Fabian Cenedese Cenedese at indel.ch
Tue Feb 10 03:07:37 CST 2004


At 16:39 09.02.2004 +0000, Huw D M Davies wrote:
>On Mon, Feb 09, 2004 at 05:03:40PM +0100, Fabian Cenedese wrote:
>> 
>> I hacked some more and need an advice. I changed font.cpp: CreateFontIndirectW
>> a bit. Instead of always allocating a new gdi object it has a list of already
>> allocated font objects and first tests if there was already a font allocated
>> with the same logical properties (LOGFONTW). If so it just returns the
>> existing HFONT and doesn't allocate a new one. With this change my
>> VB app with the many controls comes up and is almost usable. Some
>> fonts on the registers of the tab control look quite strange. But besides
>> that it works.
>> 
>> Now is this a reasonable change (apart from its hacky implementation
>> now :) ? Is the function CreateFontIndirect allowed to do something like
>> this? Are there more things I should test than just the ones in the
>> LOGFONTW struct? If anybody is interested in a screenshot (the
>> funny fonts go down by about 20 degrees :) just raise your hand.
>
>No, this isn't right.  You can convince yourself of this by a quick
>test program on Windows; initialize a LOGFONT and then call
>CreateFontIndirect twice, you'll get two different hfonts back.

My idea for caching the handles in CreateFontIndirect came from this:

GdiFont WineEngCreateFontInstance(DC *dc, HFONT hfont)
--snip--
        if(ret->hfont == hfont && !memcmp(&ret->xform, &dc->xformWorld2Vport, offsetof(XFORM, eDx))) {

Here it not only tests the properties but also the handles. So if the handles
are different (as they are now from CreateFontIndirect) it will always
create a new font. But removing this check didn't help either :)

>I suspect your leak happens in the olefont implementation.  You want
>to check that each hfont is destroyed when the IOleFont interface is
>released.

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.

Sorry for asking, I don't know much about ole, fonts and stuff :)

bye   Fabi





More information about the wine-devel mailing list