wined3d: Allow SetCursorProperties on existing cursor

[Erich Hoover]

>
> 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<http://bugs.winehq.org/show_bug.cgi?id=7619>).
I will look into changing/implementing the flags to eliminate the "non-dirty
surface" problem.

Erich Hoover
ehoover at mines.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20070310/e544bb8b/attachment.htm