Am Samstag 10 März 2007 06:10 schrieb Erich Hoover:
> Real Name:
>
Erich Hoover
> Description:
> The SetCursorProperties call needs to be capable of being performed on
> existing cursors. The current behavior removes the cursor handle at the
> beginning of any SetCursorProperties call (and on Uninit3D). The removal
> of the cursor on SetCursorProperties is counter to the documentation and
> causes some applications to lose the cursor when SetCursorProperties is
> re-issued (See Bug #7619 <http://bugs.winehq.org/show_bug.cgi?id=7619>).
> This patch corrects this issue and permits SetCursorProperties to retrieve
> the gl texture of an old cursor.
> Changelog:
> wined3d: Allow SetCursorProperties on existing cursor
This is not completely correct:
The application can Release the d3d surface after setting the cursor. This
would also delete the gl texture used to draw the cursor. Also, the apps can
potentially change the surface and call PreLoad. This would change the cursor
without SetCursorProperties(The cursor texture does not have to be in
D3DPOOL_SCRATCH, so the app can preload it manually).
But you are right, a non-dirty surface causes issues with the current code. I
think you can fix that by modifying LoadTexture not to release the surface
memory is SFLAG_FORCELOAD is passed. (Or better, fix the SFLAG_DONOTFREE
macro in wined3d_private.h). Then, when SetCursorProperties sets the surface
texture to 0 remove SFLAG_INTEXTURE from the surface flags.
The API documentation doesn't say anything about an application releasing the d3d surface, but the documentation in the code seems to indicate that the gl texture needs to remain when the surface is deleted - I did nothing to change this. What I did see as requiring a change is the call to "glDeleteTextures(1, &This->cursorTexture);" at the beginning of SetCursorProperties. Maybe I'm not understanding you correctly, but in my mind it is necessary to remove this call so that applications that re-use the same cursor can do so. This change (in combination with the change for non-dirty surfaces) was also experimentally verified to fix the problem I was experiencing (See
Bug #7619). I will look into changing/implementing the flags to eliminate the "non-dirty surface" problem.