[2/2] gdiplus: Implement GdipBeginContainer2 and GdipEndContainer
andrew at brightnightgames.com
Fri Jul 3 12:29:25 CDT 2009
Andrew Eikum wrote:
> 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
>>>> graphics objects or within a single graphics object.
>>>> I can't imagine any application depending on the uniqueness of
>>>> IDs; if they try to pass a container for graphics1 to graphics2,
>>>> 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
>>>> error calling EndContainer() with invalid values. I don't know if
>>>> 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
>>>> the same value not be returned twice?
>>> 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?
Appears it didn't attach for some reason? Attempting to re-send, also
More information about the wine-devel