user32: Track the number of GL surfaces for a window rather than the pixel format.

[Ken Thomases]

On May 7, 2014, at 3:17 AM, Alexandre Julliard wrote:

> Ken Thomases <ken at codeweavers.com> writes:
> 
>> Well, it doesn't make much sense for user32 to know the particular pixel format, either.  There's not a single pixel format for each window.  WGL and D3D can use separate formats.  That's at the center of what I'm doing.
>> 
>> A change to use a boolean flag instead of a pixel format ID would be as complicated for user32 as this patch and would make the driver work more complicated.
> 
> It's already treated as a flag as you noted, so I don't see why you'd
> need to change anything.

The _effect_ is of a flag, but it's called a pixel format.  It'd be nice to fix its name to match its interpretation.  And, besides the renaming, the only other change that my patch made to user32 was changing a single "=" to "+=".  I don't feel like it's adding much in the way of complexity.


>> It seems to me that this is purely a practical matter.  We need user32 to behave differently when there's any GL surface(s) than when there are none.  Something has to keep count and it seems simplest to track the count in user32.
> 
> Surely the driver already knows if there are surfaces, I don't see why
> you need a count at all, much less in user32.

It's the difference between code which, when a surface is destroyed, simply decrements that count in user32 vs. one which has to search in two different lists to see if there are any remaining surfaces for that window and, if there aren't, clearing the "flag" in user32.  It's not particularly difficult, it's just simpler and cleaner with a count.  Putting it in the driver means adding complexity into each driver.

This entire piece of functionality in user32 is for the benefit of the driver.  It's all implementation detail.  I don't understand why it shouldn't take the form that's most suited to the needs of the driver.

-Ken