--
v3: ntdll: Support old parameter layout for NtSetInformationProcess( ProcessInstrumentationCallback ).
ntdll: Call instrumentation callback for KiUserModeCallback on x64.
ntdll: Call instrumentation callback for LdrInitializeThunk on x64.
ntdll: Call instrumentation callback for KiUserExceptionDispatcher on x64.
ntdll: Call instrumentation callback from wine_syscall_dispatcher on x64.
ntdll/tests: Add more tests for process instrumentation callback.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6446
On Fri Sep 13 18:40:16 2024 +0000, Nikolay Sivov wrote:
> It looks to me that there won't be any way to retroactively apply fill
> mode later, once you have copied all the vertices. But I'm not sure
> what's the correct way would be here.
In my opinion the correct way would probably be populating a joint CDT from all the geometries and then erasing triangles depending on the fill_mode. However, this is a bigger undertaking and for the [bug](https://bugs.winehq.org/show_bug.cgi?id=51139) at hand it suffices to just concatenate all lists, since it seems the application uses the geometry groups for assembling glyphs to words and render them all at once. Due to the latter, there is no intersection between the different geometric entities.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82177
Nikolay Sivov (@nsivov) commented about dlls/d2d1/geometry.c:
> HRESULT d2d_geometry_group_init(struct d2d_geometry *geometry, ID2D1Factory *factory,
> D2D1_FILL_MODE fill_mode, ID2D1Geometry **geometries, unsigned int geometry_count)
> {
> - unsigned int i;
> + unsigned int i, j;
> + struct d2d_geometry *other_geom;
> + D2D_MATRIX_3X2_F g, gplain;
> + size_t f_vertex_count, f_face_count, f_bezier_vertex_count, f_arc_vertex_count;
> + size_t o_vertex_count, o_face_count, o_bezier_count, o_bezier_face_count, o_arc_count, o_arc_face_count;
>
> + FIXME("Ignoring fill_mode=%#x!\n", fill_mode);
It looks to me that there won't be any way to retroactively apply fill mode later, once you have copied all the vertices. But I'm not sure what's the correct way would be here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82167
On Fri Sep 13 17:35:55 2024 +0000, Rémi Bernon wrote:
> Not sure what to say other than it's pretty arbitrary. Larger than
> common read sizes, to reduce the chances of having to call the callbacks
> multiple times, but otherwise nothing very interesting about it. Maybe
> it should even be a bit shorter to avoid wasting two 64k page instead of
> one though.
Right, guess it's something to test and optimise once all the code is in. Thanks
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6480#note_82153