- 25 May, 2023 4 commits
-
-
Francois Gouget authored
-
Francois Gouget authored
-
Alex Henrie authored
-
Tim Clem authored
lparam != 0 does not imply lparam_size is big enough for a MSG, so we can end up manipulating memory past the end of the buffer. Co-authored-by: Jacek Caban <jacek@codeweavers.com>
-
- 24 May, 2023 28 commits
-
-
Alexandros Frantzis authored
Update the desktop window size to match the current virtual screen rect.
-
Alexandros Frantzis authored
Use a driver internal window message to dispatch updates to display devices from the desktop window thread.
-
Alexandros Frantzis authored
Store all incoming Wayland output state as pending and make it current in a thread-safe way when the "done" event arrives. This enables other threads, with proper locking, to safely read consistent and complete Wayland output information.
-
Alexandros Frantzis authored
Handle Wayland output events sent after process initialization, and update the win32u display devices when handling these events in the desktop window process.
-
Alexandros Frantzis authored
Create a dedicated thread from which we read and dispatch Wayland events (beyond the initial ones).
-
Alexandros Frantzis authored
There is currently no benefit to dynamic allocation, and static allocation allows us to simplify some aspects of initialization.
-
Zebediah Figura authored
-
Zebediah Figura authored
-
Zebediah Figura authored
-
Paul Gofman authored
VPN interfaces often have ARPHRD_NONE in ifr_hwaddr.sa_data but IFF_POINTOPOINT flag set.
-
Davide Beatrici authored
-
Davide Beatrici authored
-
Davide Beatrici authored
-
Anton Baskanov authored
-
Anton Baskanov authored
-
Anton Baskanov authored
-
Anton Baskanov authored
-
Anton Baskanov authored
It's less physically correct but closer to the native behavior.
-
Anton Baskanov authored
-
André Zwing authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
We are not going to support multi-machine .so modules.
-
- 23 May, 2023 8 commits
-
-
Davide Beatrici authored
programs/explorer/desktop.c:104:16: warning: ‘hres’ may be used uninitialized in this function [-Wmaybe-uninitialized] 104 | return hres; | ^~~~
-
Bartosz Kosiorek authored
Using TransformMatrixPoints is not needed and all values could be taken from transformation matrix: - ShearX from m11, m12 - ShearY from m21, m22 - Translation mdx, mdy The result could be calculated by taking destination points values: {{0.0, 0.0}, {1.0, 0.0}, {0.0, 1.0}} and calculating it with GdipTransformMatrixPoints function: dst_to_src_points[0].X = dst_to_src.matrix[4]; dst_to_src_points[0].Y = dst_to_src.matrix[5]; dst_to_src_points[1].X = dst_to_src.matrix[0] + dst_to_src.matrix[4]; dst_to_src_points[1].Y = dst_to_src.matrix[1] + dst_to_src.matrix[5]; dst_to_src_points[2].X = dst_to_src.matrix[2] + dst_to_src.matrix[4]; dst_to_src_points[2].Y = dst_to_src.matrix[3] + dst_to_src.matrix[5];
-
Bartosz Kosiorek authored
Improves efficiency by using addition instead of float numbers multiplication for destination points. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947
-
Bartosz Kosiorek authored
With previous implementation, every iteration pointer value was calculated by taking row and column of the image. It needs multiply calculation. With current implementation, pointer value calculation, is replaced with iterator, which takes next pixel data. It improves efficiency by using addition instead of multiplication for iterating through points data. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947
-
Bartosz Kosiorek authored
Calculating transformation points and not using it it is a waste of CPU time. With this patch the code was moved where it is used. It is improving performance of GdipDrawImagePointsRect when resampling is not needed. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53947
-
Paul Gofman authored
-
Paul Gofman authored
-
Paul Gofman authored
-