--
v2: riched20: Implement ITextDocument::Freeze and ITextDocument::Unfreeze.
riched20: Don't assume that TxDraw preserves the device context's brush selection.
riched20/tests: Test for ITextDocument::Freeze and ITextDocument::Unfreeze.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2331
> Do you see any other way out of this? I mean specifically the case when an app sets GL pixel format itself on a window. I was thinking about whether it is possible to make setpixelformat quicker in winex11 instead and I don't see how. If keeping direct presentation it will require some X window reconfigure which is not going to be anywhere quick. Otherwise, it can be technically made to work like for GL child window redering (keeping composite redirected drawables for different pixel formats) but that requires essentially the same blitting on each present as done with wined3d backup context.
>
> The other different (but a bit complicated) way would be to:
>
> * count statistics of GL pixel format switches;
> * introduce switching back from backup context and switch between resetting pixel format or switching to backup context or back based on that.
Assuming that recreating the GLX drawable is always worse than a GDI blit, I think this patch is the right direction. I just don't want to regress performance in backends other than x11.
So maybe the right approach here is to add some boolean flag saying "return an error if changing the pixel format would be expensive". Or maybe things are already broken on winemac and the right approach is just to punt.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26147
`mincore()` is not a reliable way to determine whether a region is empty. This could result in an already-in-use region being mapped with `MAP_FIXED`, and Wine conflicting with its original owner (i.e. dyld).
With the `mincore()` check removed, a special case was added to allow zero-fill sections to be mapped.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2329
This change only implements case-sensitivity of technique keywords and related checks when corresponding profile is used. My immediate plan is to add some synthetic type for technique variables, for example as {object, void}, then add named techniques as variables. This is useful because these names are participating in global scope, and should not collide with normal variables. After that "pass_list" will be split, at least in two variants because of how much d3d9 syntax differs. Some trivial changes will be need later to have some top level fx compilation helper that considers only fx objects and calls ps/vs/gs compiler to create inner shader blobs on same original source.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/111
On Windows RegEnumValueA() is buggy such that when the value name
buffer is too small, it may way overestimate the required data buffer
size, sometimes returning more than the sufficiently large buffer it was
provided, in which case that buffer is untouched and thus not
NUL-terminated.
So modify the tests to accept this broken result and avoid checking
out-of-bounds data.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=53172
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2324
Return directly in case of success so exiting the loop only happens in
case of error.
Better identify which statements prepare the next attempt / set things
up in case the table allocation failed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2312