ENTER_GL and ActivateContext question

Alexander Dorofeyev alexd4 at inbox.lv
Fri Dec 14 00:25:16 CST 2007


Hello.

I've spent some time trying to get into this stuff and what can be improved in 
IWineD3DSurfaceImpl_BltOverride. Code that does glDrawBuffer in the Colorfill 
path and possibly elsewhere indeed appears to be redundant to ActivateContext 
and probably should go. That's in theory :), in practice though I've run into 
some problems. IWineD3DDevice_Clear call that it uses to perform the job does a 
thing that looks strange to me:

ActivateContext(This, This->render_targets[0], CTXUSAGE_CLEAR);

So whatever the IWineD3DSurfaceImpl_BltOverride does to properly ActivateContext 
select draw buffer etc may be overriden by ActivateContext within 
IWineD3DDevice_Clear seemingly. This looks buggy(?). Often things still get 
drawn properly because ActivateContext within IWineD3DDevice_Clear in many cases 
doesn't see a need to change context or do glDrawBuffer, so nothing happens even 
though it's passed not that render target which should get cleared. My recent 
change to BltOverride though made problems more likely, in fact it appears it 
broke something as basic as ddraw colorfill to the front buffer / primary 
surface if a back buffer exists :(, because now in such case ActivateContext 
called from Clear with wrong target is guaranteed to do its job and back buffer 
gets cleared instead.

Do you have any advices on how to handle that? In my tests I tried to use 
Get/SetRenderTarget before calling Clear, and restore the old one afterwards, 
which seems to make the colorfill work right on front buffer, but maybe there 
are better/less overhead ways to force Clear to pass right render target to 
ActivateContext? Or maybe something along the lines of device->isInDraw 
mechanism I saw in few other places, to tell Clear not to bother with 
ActivateContext at all?



More information about the wine-devel mailing list