[cairo] Huge leak in Cairo/win32

[Hans Breuer]

On 24.02.2005 22:07, Owen Taylor wrote:
> On Thu, 2005-02-24 at 21:47 +0100, Hans Breuer wrote:
> 
> 
>>>>Stupid question - can't we just delete the DC first rather
>>>>than after the bitmap? won't that automatically unselect the bitmap
>>>>and let us delete it afterwards?
>>>
>>For me this sounds like relying on an undocumented side-effect instead
>>of using the documented way to go. Although it may work on some
>>platforms it may not on others.
>>Relying on undocumented behaviour should IMHO be avoided where ever
>>possible (although I'm a big fan of minimizing code size).
> 
> 
> [ Note, academic argument follows, I switched over to the method
>   you are suggesting earlier]
> 
> Where is your method documented? There is not a single place in
> the SDK docs (other than in some of the examples) that I can find
> that describes a need to save the initial bitmap and restore it.
> 
Huh? In every documenation of SelectObject? From MSDN installed with vc6 :

"
This function returns the previously selected object of the specified type. 
An application should always replace a new object with the original, default 
object after it has finished drawing with the new object.

An application cannot select a bitmap into more than one DC at a time.
"

> It is documented that you can't delete a bitmap selected into a DC,
> but once the DC is deleted, the bitmap can't be selected into it,
> can it?
> 
I don't get it ;-)

> 
>>>Tried this and it seemed to work fine, so I committed that change.
>>>
>>
>>Not looking at the code but: isn't this only significantly decreasing
>>the size of the leak - but still leak? Now the 1x1 pixel sized
>>bitmap, which initially got selected into the device context.
> 
> 
> That doesn't make sense: with your method the 1x1 bitmap is selected
> into the DC when it is destroyed. Windows doesn't delete the
> bitmap selected into the DC (or we wouldn't have this leak), so why
> is the bitmap deleted in your model?
>
My suggestion follows the documentation from above and yes there needs
to be some other mechanism than simple refcounting. Maybe just an in
kernel map of object selected into specific DCs, just speculating
though ...

> My assumption is that the 1x1 bitmap is somehow special and magic
> and doesn't need to be destroyed. I wouldn't be surprised if it
> is a singleton object. Either that or it is automatically tied to the 
> DC in some fashion.
> 
Maybe, as the behaviour does not seem to be specific to bitmaps at all:
"the original, default object". OTOH the bitmap appears to be the only
object which can be changed, e.g. make it black or white. So it may as
well have some special connection to the original DC and get destroyed
in the exact moment when the DC gets destroyed.

	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it.                -- Dilbert