[4/6] WineD3D: Attempt to clean up fbos only if a gl surface is destroyed

H. Verbeet hverbeet at gmail.com
Thu Jul 19 02:10:14 CDT 2007

On 19/07/07, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> What I meant was that selecting the gl codepath or the no gl codepath. This is
> preferably done by calling a COM method on the right vtable(d3d surface / non
> d3d surface). My first patch(never sent here) checked the vtable address to
> find out if the surface is d3d or gdi, this was ugly. Now this patch checks a
> device internal status flag, which is better because the device can decide on
> which path to take based on it's own properties, rather than depending on the
> surface type.
I think the flag is fine. Executing that part of the code or not
doesn't really depend on the surface type. GDI surfaces would never be
attached to an FBO anyway, it's the GL_LIMITS(buffers) that would
cause problems here. Making sure the limit is 0 if GL isn't available
would probably work as well.

More information about the wine-devel mailing list