--
v3: mf: Handle errors with source event generator in session.
mf/test: Test error case when session is streaming.
mf/test: Move stream sink stub above media sink stub.
mf/test: Test error cases in media sesssion.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3789
This defines (and, broadly, implements) the API for mapping sm1 combined
samplers to the target environment. This is possibly the simplest bit of API for
sm1 support thus far.
It does not actually involve any API changes. Rather, each combined sampler is
split into two descriptors, one for the sampler and one for the texture, both
with the same binding index as the original combined sampler.
--
I feel rather positive about this bit of API. it required very little design
concern or implementation difficulty on the vkd3d side.
On the Wine side, it required quite a lot of change, but I think pretty much all
of that change was positive on its own merits, and should probably be applied
independently of the sm1/Vulkan work. We've talked about translating
wined3d_device_set_sampler_state() and wined3d_device_set_texture() to
wined3d_device_set_sampler() and wined3d_device_set_shader_resource_view() for
quite some time now, and that was pretty much exactly what was required to make
this work—that and choosing the obvious mapping of "same index for both state
objects".
The most obvious alternative to this design, to me, would be to reroll
struct vkd3d_shader_interface_info (or extend it without rerolling), adding a
new array for mapping a combined sampler in the *source* environment to two
separate descriptors in the *target* environment, i.e.
struct vkd3d_shader_resource_binding in reverse. We would probably also want to
design a way to map a combined sampler to a combined sampler (a sixth array? Or
reuse struct vkd3d_shader_descriptor_binding with a new descriptor type?)
I suppose the advantage of such an alternative design would be that it reports
"one" descriptor as "one", not "two", but the associated complexity seems far
greater, and accordingly I don't really want to give it the time of day. (Note
also that this patch set handles combined -> combined mapping without any extra
effort). I will of course yield to maintainer preference, though.
--
As before, I've prepared proof-of-concept code for Wine. The branches are here:
https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5https://gitlab.winehq.org/zfigura/wine/-/commits/himavant6
The relevant test can be run with:
make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/tex2D.shader_test
These branches are rather larger than the previous ones. By way of summary, the
vkd3d branch contains these patches, plus about two dozen patches to hook up sm1
tests and to fix various corner cases surrounding semantic translation (much of
which should be rewritten with a VSIR-based "lowering" approach in mind).
The Wine branch contains:
* Wine merge request 4027,
* the patches for sm1 constant buffers,
* a set of patches to transform individual sampler states into sampler objects
(of which [1] is the most interesting), and
* a set of patches to transform textures into SRVs (of which [2] is the most
interesting).
As described above, there is not actually any part of the Wine side that touches
the vkd3d-shader interface.
[1] https://gitlab.winehq.org/zfigura/wine/-/commit/984e478763c99157a6ec49388fe…
[2] https://gitlab.winehq.org/zfigura/wine/-/commit/722c1bf1f6a7691c9ed431bd433…
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/394
Nikolay Sivov (@nsivov) commented about dlls/dwrite/gdiinterop.c:
> return hr;
> }
>
> - scaled_run = *run;
> - scaled_run.fontEmSize *= target->ppdip;
> - hr = IDWriteFactory7_CreateGlyphRunAnalysis(target->factory, &scaled_run, &target->m, rendermode, measuring_mode,
> + scaled_matrix = target->m;
> + scaled_matrix.m11 *= target->ppdip;
> + scaled_matrix.m22 *= target->ppdip;
> + hr = IDWriteFactory7_CreateGlyphRunAnalysis(target->factory, run, &scaled_matrix, rendermode, measuring_mode,
> gridfitmode, target->antialiasmode, originX, originY, &analysis);
> if (FAILED(hr))
The reason we currently modify font size is to produce better quality output. If you keep original size, then scale 10 times, it won't necessarily be looking good. Regarding matrix modification, how does that work for other components, for e.g. rotation? Maybe we should multiply by diagonal matrix instead?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3718#note_48043
--
v2: uiautomationcore: Use EVENT_OBJECT_FOCUS to advise HWND providers of focus change events in the COM API.
uiautomationcore: Query EVENT_OBJECT_FOCUS HWND for a serverside provider if there is a registered focus change event handler.
uiautomationcore/tests: Add tests for IUIAutomationFocusChangedEventHandler event advisement behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4024