Request for Review: Cursor & Icon patches
javatroubadour at yahoo.com
Fri Jul 24 21:46:09 CDT 2009
I haven't heard anything, so if anybody can find the time I would greatly appreciate it.
--- 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
> * Cursors & icons stored in non-moveable memory block
> (a.k.a., "32 bit
> data") in addition to existing 16-bit moveable
> * 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
> * Adds more complete .ani support (I think nearly 100%
> * 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
> 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
> 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
> -----Inline Attachment Follows-----
More information about the wine-devel