Re: [PATCH 1/3] user32/winex11: Move 32-bit cursor/icon structure to 32-bit header.
Erich Hoover <ehoover(a)mines.edu> writes:
--- a/include/winuser.h +++ b/include/winuser.h @@ -98,6 +98,17 @@ typedef HANDLE HDWP; #define WSF_VISIBLE 1 #define DF_ALLOWOTHERACCOUNTHOOK 1
+typedef struct tagWINECURSORICON { + POINT ptHotSpot; + WORD nWidth; + WORD nHeight; + WORD nWidthBytes; + BYTE bPlanes; + BYTE bBitsPerPixel; + DWORD frame_size_and; + DWORD frame_size_xor; +} WINECURSORICON;
You can't do that, private structures have nothing to do in public header files. They also can't be part of the user driver API. -- Alexandre Julliard julliard(a)winehq.org
On Wed, Feb 10, 2010 at 3:36 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
... You can't do that, private structures have nothing to do in public header files. They also can't be part of the user driver API. ...
I'm sorry it's taken me so long to get back on this issue, I've been attempting to come up with, and test, an alternative solution. The original patch was approached with a mind toward keeping the code as similar as possible to what is currently done. I have attached a redesign of this patch that instead approaches the problem by storing and retrieving cursors/icons as ICONINFO structures. This mechanism allows the storage of all the necessary bitmap data (bpp, planes, width, etc.) in addition to the hotspot information without relying on a custom structure. My goal here is to have something simple that can be passed to the driver and can later be extended to animated cursors. In this case the extension would be to pass to pSetCursor() an array of ICONINFO pointers, the total number of frames, and the time between frames. A bonus with this method is that each frame of the cursor could then have a different hotspot (I'm not sure if anyone has actually ever used this in an animated cursor, but it is possible from what I've seen of the format). Anyway, I am hoping that the attached patch is more palatable and I am interested in any and all comments or suggestions. Erich Hoover ehoover(a)mines.edu
Erich Hoover <ehoover(a)mines.edu> writes:
I'm sorry it's taken me so long to get back on this issue, I've been attempting to come up with, and test, an alternative solution. The original patch was approached with a mind toward keeping the code as similar as possible to what is currently done. I have attached a redesign of this patch that instead approaches the problem by storing and retrieving cursors/icons as ICONINFO structures. This mechanism allows the storage of all the necessary bitmap data (bpp, planes, width, etc.) in addition to the hotspot information without relying on a custom structure.
My goal here is to have something simple that can be passed to the driver and can later be extended to animated cursors. In this case the extension would be to pass to pSetCursor() an array of ICONINFO pointers, the total number of frames, and the time between frames. A bonus with this method is that each frame of the cursor could then have a different hotspot (I'm not sure if anyone has actually ever used this in an animated cursor, but it is possible from what I've seen of the format). Anyway, I am hoping that the attached patch is more palatable and I am interested in any and all comments or suggestions.
That's clearly better, it's going in the right direction. I think the first step should be to write more test cases, in particular for cursor bitmaps that don't match the screen depth, I suspect that still doesn't work right when going through DDBs. Also we'd need to know exactly how GetIconInfo() behaves for animated cursors. -- Alexandre Julliard julliard(a)winehq.org
On Tue, Feb 16, 2010 at 10:35 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Erich Hoover <ehoover(a)mines.edu> writes:
I'm sorry it's taken me so long to get back on this issue, I've been attempting to come up with, and test, an alternative solution. The original patch was approached with a mind toward keeping the code as similar as possible to what is currently done. I have attached a redesign of this patch that instead approaches the problem by storing and retrieving cursors/icons as ICONINFO structures. This mechanism allows the storage of all the necessary bitmap data (bpp, planes, width, etc.) in addition to the hotspot information without relying on a custom structure.
My goal here is to have something simple that can be passed to the driver and can later be extended to animated cursors. In this case the extension would be to pass to pSetCursor() an array of ICONINFO pointers, the total number of frames, and the time between frames. A bonus with this method is that each frame of the cursor could then have a different hotspot (I'm not sure if anyone has actually ever used this in an animated cursor, but it is possible from what I've seen of the format). Anyway, I am hoping that the attached patch is more palatable and I am interested in any and all comments or suggestions.
That's clearly better, it's going in the right direction. I think the first step should be to write more test cases, in particular for cursor bitmaps that don't match the screen depth, I suspect that still doesn't work right when going through DDBs. Also we'd need to know exactly how GetIconInfo() behaves for animated cursors.
Note I don't know anything about the current mouse code. I guess the depth issues are similar to what I encountered during my xrender dibsection work. E.g. XCopyArea not working between between bitmaps of different depths. In this case it is about the mouse cursor then. I think you won't encounter the depth issue if you use the XRender cursor APIs. It offers similar functionality to the normal XCursor APIs but likely coupled with the advantages of XRender. I have no idea if 32-bit DDBs are needed though but those should be easy to add now. I didn't submit ptaches for that because there are some tricky bugs which still have to be fixed. Roderick
participants (3)
-
Alexandre Julliard -
Erich Hoover -
Roderick Colenbrander