COLORONCOLOR(STRETCH_DELETESCANS) was used in place of HALFTONE. COLORONCOLOR mode may delete rows
of pixels without trying to preserve information so it will cause Wine to render poorly when the
destination rectangle is small.
According to tests, HALFTONE mode uses box filter when doing integer downscaling and nearest
neighbor interpolation when doing upscaling in both horizontally and vertically. In other cases,
HALFTONE mode uses a lanczos3 like algorithm to interpolate pixels. There are also other heuristics
involved. For example, shrinking a 2x2 image to 1x1 may not use box filter depending on image data.
Since this algorithm is undocumented, it's difficult to reverse engineer the original algorithm and
produce identical results. Instead, this patch uses a naive implementation of bilinear interpolation
to implement HALFTONE mode and it produces good quality images.
For 8-bit and lower color depth images, nulldrv_StretchBlt should resize the images first and then
converts color depth.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46375
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular this stops the traces in open_clipboard() and
has_no_open_wnd() from clobbering the line number when used in
expressions such as ok(has_no_open_wnd(), ...).
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
One of the tests expects GetLastError() to still return 0xdeadbeef after
has_no_open_wnd(), which would not be the case if another process did
open the clipboard.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As for OpenClipboard(), if another application opened the clipboard,
GetOpenClipboardWindow() will not return the expected value.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Applications using ole32's clipboard API (e.g. Radeon / QT5) end up
monitoring the content of the clipboard and calling OpenClipboard()
while user32:clipboard runs. This causes the test's own
OpenClipboard() calls to fail.
Similarly the KDE clipboard manager may query the Wine clipboard
content while the test runs, causing winex11.drv to call
OpenClipboard() with the same effect.
So call OpenClipboard() again when it fails due to the clipboard
already being open. If opening the clipboard still fails, trace who
opened the clipboard, particularly the window class name to help
identify the source of interference.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This ensures all traces have the relevant context information, in
particular the OpenClipboard() checks, and simplifies the ok() calls.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
One cannot assume that a random integer has zero chance of being a valid
atom.
Reenable the GlobalFindAtomA() check in a todo_wine.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
By default CF_LOCALE matches the current input language, not the default
user LCID.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reduce the time to run the monitor test from 6 minutes to 25 seconds.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50086
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
They are very old and likely no longer relevant.
Signed-off-by: Francois Gouget <fgouget@free.fr>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
At least on recent Windows, the HKL values are a combination of user
selected UI language in the low word, and keyboard layout id in the high
word.
The keyboard layout id used in HKL is sometimes different from its name,
as returned by GetKeyboardLayoutName, in which case it's the "Layout Id"
value in the corresponding registry key under the layout name.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Validating that SendInput with INPUT_HARDWARE type should be no-op.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50506
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since whole_rect / client_rect are updated asynchronously, there may be
a small lag between X11 and Wine regarding the expected window position.
Then, as events' x and y fields are reported relative to the X11 window
position, this lag can cause inconsistencies when we compute absolute
mouse positions.
Also, applications that control their own position while being moved
cause additional whole_rect / client_rect updates, before X11 knows
about it.
This can make applications like Winamp go nuts when they are being moved
and move all over the place "randomly".
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46309
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The WmShowRestoreMinimizedOverlappedSeq message sequence in tests
clearly show that there is a WM_ACTIVATE message at the end of
ShowWindow() calls after restoring a minimized window, and it's
not from SetFocus().
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47507
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It looks like that GetKeyState is supposed to catch key presses when
called from a background thread even after its thread message queue and
thread input structures have been created.
This happens in Bioshock 2 Remaster, and causes the game to stay forever
on a "Press space to continue" screen, as the thread checking for space
key press calls GetKeyState repeatedly (and PeekMessage), although it's
in background.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=26269
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some applications (e.g. Lego Worlds, Hitman 2) use (-32000,-32000) to
determine whether a window is minimized.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Even though MSDN says 0 and 1 are both valid and they represent the default refresh rate of display
hardware. Some games rely on the value being the real refresh rate and use it to cap frame rates.
Fix an issue that Sakuna: Of Rice and Ruin reports monitors of 1Hz and cap to 1fps.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zhiyi Zhang