[2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer

[Andrew Eikum]

Nikolay Sivov wrote:
> Vincent Povirk wrote:
>> On Fri, Jul 3, 2009 at 10:00 AM, Andrew
>> Eikum<andrew at brightnightgames.com> wrote:
>>  
>>> I agree that the behavior of the container IDs doesn't match native.
>>>  However, do we really care to duplicate that behavior?  I can't see 
>>> any
>>> documentation in MSDN that says container IDs must be unique across 
>>> either
>>> graphics objects or within a single graphics object.
>>>
>>> I can't imagine any application depending on the uniqueness of 
>>> container
>>> IDs; if they try to pass a container for graphics1 to graphics2, 
>>> nothing
>>> happens, so there's no behavior to depend on.  Ditto for invalid or
>>> already-used containers.  The only scenario I can think of where the
>>> uniqueness of container IDs would be a dependency would be an 
>>> application
>>> error calling EndContainer() with invalid values.  I don't know if it's
>>> worth the effort of making a handle table and whatnot to work around an
>>> application glitch that might not even exist.
>>>
>>> So, I would argue against the validity of the test you quote.  Why 
>>> should
>>> the same value not be returned twice?
>>>     
>>
>> +1
>>
>> If an application does need the ID's to be more like Windows, the code
>> can be changed to account for it. We don't have to match every quirk
>> of Windows the first time something is implemented.
>>   
> Exactly. I'm not talking about that. Allocating handle on Begin..() or 
> Save..() and releasing it on
> End...() or Restore...() should be enough. After that we will probably 
> never want to change that
> but for a first time it's necessary I think.

Okay, how about this patch?  It creates a list of available IDs and 
assigns/releases them as needed.  Seems to work fine from my testing.  
It also adds some fixes for things Vincent pointed out last night.

Can you guys check if everything is done correctly from a C/Wine 
perspective?  I notice that the objects in availableGCIDs are never 
explicitly freed; can we just let this happen during cleanup as the 
program exits?