Request for Review: Cursor & Icon patches

[Daniel Santos]

I haven't heard anything, so if anybody can find the time I would greatly appreciate it.

Thanks,
Daniel

--- On Thu, 7/23/09, Daniel Santos <javatroubadour at yahoo.com> wrote:

> From: Daniel Santos <javatroubadour at yahoo.com>
> Subject: Cursor & Icon patches
> To: "wine-devel" <wine-devel at winehq.org>
> Date: Thursday, July 23, 2009, 1:59 AM
> Hello everybody!
> 
> Attached is my current cursor icon patches based upon work
> by Henri Verbeet and Andrew Riedi for review and
> comment.  I finished the actual code about 3 weeks ago,
> but it's been a lot of work for me to split it out into
> smaller pieces, especially being new to git.  Here is a
> break-down of what these patches do and the theory.
> 
> * Adds real 32-bit handles (instead of converting 16-bit
> handles to 32
>   bit).
> * Cursors & icons stored in non-moveable memory block
> (a.k.a., "32 bit
>   data") in addition to existing 16-bit moveable
> block.
> * A new 'struct cursor_header' (include/wine/winuser16.h)
> is pre-pended
>   to the 32-bit cursor/icon data (16-bit data format
> is untouched).
> * A new 'struct cursor_map_entry'
> (dlls/user32/cursoricon.c) is used to
>   manage a cursor's association with its handles and
> data.
> * Adds more complete .ani support (I think nearly 100%
> complete).
> * Adds themed icon support (from your X-windows theme).
> * Fixes a lot of bugs.
> * And finally, moves cursors to the server.
> 
> The server opaquely stores the raw 32-bit cursor/icon
> data.  Since the client does all interaction with
> winex11.drv, the server doesn't really need to understand
> it.  The client caches all objects locally, but
> attempts to retrieve from the server any handle it doesn't
> know about.  Locally, the client uses a pair of rbtrees
> to associate cursor objects (actually struct
> cursor_map_entry) with their respective 16 & 32 bit
> handles.  The 16 bit cursor data is automatically
> generated on the client and can still be directly
> manipulated from 16 bit programs; in such cases, the 32-bit
> cursor data will be updated from the modified 16 bit
> data.  The CRITICAL_SECTION IconCrst is used to
> synchronize access to the rbtrees and ensure that data is
> unmodified once an operation on that data begins (in
> database terms, IconCrst is used to lock the entire "table"
> and there's no "row-level" locking).
> 
> 
> There are several new functions to query and manipulate the
> rbtrees:
> 
> add_cursor_entry   : (self-explanatory)
> remove_cursor_entry: (self-explanatory)
> get_cursor_handle16: retrieves a 16-bit handle from a
> 32-bit one
> get_cursor_handle  : visa-versa
> 
> 
> Layered on top of that are a basic set of functions for
> higher level management of cursor/icon objects:
> 
> alloc_cursor_data   : allocate &
> initialize cursor data & header
> create_cursor       : creates
> cursor and auto-generates 16-bit data
> destroy_cursor      : destroys cursor and
> associated 16-bit data
> get_cursor_entry    : will look both locally and
> on the server
> get_cursor_object   : returns the cursor's
> data
> update_cursor_data16: creates or updates the 16-bit data
> from 32-bit data
> CURSORICON_refresh_cursor16: updates the 32-bit data from
> 16-bit data
> 
> The functions add_cursor_entry and get_cursor_entry
> directly return a pointer to the struct cursor_map_entry and
> therefore require locking IconCrst in advance of calling (or
> will fail an assertion).  Having direct access to the
> cursor_map_entry reduces complexity in some circumstances.
> 
> One of the oddest fixes is the fake_cursor() function,
> which is used to accommodate deleting the active cursor,
> which windows doesn't mind.  This isn't the only way to
> go about it, but the alternative was to make the cursor
> empty and I'm not certain that that is the visual behavior
> of windows when deleting the active cursor, so I'm more than
> open to feedback on that as well as anything else in these
> patches.
> 
> Thanks!
> Daniel
> 
> 
>       
> -----Inline Attachment Follows-----
> 
> 
>