[4/6] WineD3D: Attempt to clean up fbos only if a gl surface is
destroyed
Stefan Dösinger
stefandoesinger at gmx.at
Thu Jul 19 04:23:20 CDT 2007
Am Donnerstag, 19. Juli 2007 09:10 schrieb H. Verbeet:
> 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.
Exactly, the GL_LIMITS is the problem. The gl info structure is stored in the
adapter, and the adapter is found via a pointer in the device. If there is no
gl there is no d3d adapter, ergo the pointer is NULL.
Making sure that GL_LIMITS does not crash but just returns 0 sounds tempting,
but I am afraid that this provokes more nasty issues. We should just watch
out not to call it without gl, and crashing if we do is a nice way to show us
that something is wrong.
More information about the wine-devel
mailing list