The GIF LZW compression algorithm was incorrectly initializing the code
size to 8 bits regardless of the actual color depth. This caused issues
with images that have fewer colors requiring smaller initial code sizes.
The fix calculates the proper initial code size based on the actual
number of colors in the image, using the formula: minimum code size =
max(2, ceil(log2(color_count))). This ensures proper compression for
images with small color palettes and maintains compatibility with GIF
decoders that expect correct LZW initialization parameters.
Log: Fixed GIF compression for images with small color palettes
Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9486
On Thu Nov 13 17:08:33 2025 +0000, Esme Povirk wrote:
> According to MSDN, this will fail if the file isn't opened with write
> permission (which, I think, shows that the tests aren't testing what you want).
Yes, I need to spend some time rewriting new test cases to test the Flush method of ILockBytes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9431#note_122495
On Fri Nov 14 08:13:36 2025 +0000, Rémi Bernon wrote:
> This looks complicated and we probably don't want to touch the X11 event
> queue outside of ProcessEvents. There's already
> `EVENT_x11_time_to_win32_time` which estimates the X server time, and it
> is used in `set_input_focus` for the same kind of purpose as you need here.
> It might not be very accurate though, and if you need it to be, maybe it
> would be better to find a way to detect remote vs local X server and
> check / assume that a local server uses `clock_gettime` /
> `CLOCK_MONOTONIC` for its time which I believe most if not all
> implementations do (or some other clock, I'm not 100% confident).
Yes, I need to take some time to figure out the best way to implement this. The timestamp property of the clipboard may be modified by different applications, so I need to find a more precise method to set it. This is to prevent incorrect settings that could cause VMware to use this timestamp for judgment, leading to errors and the inability to paste.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_122494
Current code attempts to copy a file to itself. File is not actually copied; instead, a file sharing error is received. This result is ugly and differs from native. Behavior now appears to be the same as native with changes in this MR .
--
v14: xcopy: Don't attempt to copy a file to itself.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9112
We used to do this when drawing the image. But our tests show that for v6,
the image bitmaps have been alpha pre-multiplied before drawing.
So we should do this when adding images.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9348
Fixed a memory leak in IPropertyStorage_fnDeleteMultiple when deleting
properties by name. Previously, when deleting a property by its name,
the code only removed the property from the propid_to_prop dictionary
but failed to clean up the bidirectional mapping between property names
and IDs in the propid_to_name and name_to_propid dictionaries. This
resulted in orphaned dictionary entries and memory leaks.
The fix ensures proper cleanup of both dictionaries when deleting
properties by name by:
1. Looking up the property name in the name_to_propid dictionary
2. Removing the property from propid_to_prop dictionary
3. Also removing the bidirectional mappings from propid_to_name and
name_to_propid dictionaries
Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9485