On Tue Feb 13 16:54:26 2024 +0000, Yuxuan Shui wrote:
> @rbernon is there anything left i need to do to get this merged?
Like we discussed I now think this should be implemented more like native. As far as I can tell it uses the existing track classes and parses MIDI files into them, dispatching the events on each track and creating new tracks if needed depending on the event types.
This could actually make the implementation simpler as many track classes are already partially implemented, so it'd just be a matter of filling them with the parsed MIDI events.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4982#note_61016
It can be substantially faster in some cases. Notepad++ (with several plugins) start up goes down from around ~1.03 sec to ~0.61 sec on my machine (with wineprefix active).
9b7669592d6f8b40976b571b70f8543777d35167 is what introduced this performance regression. I don't know why exactly, but it made my Notepad++ noticeably slower when launched from a file manager (so it's not just at wineprefix startup overhead), which is very annoying.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5070
There are still some issues I need to fix, mainly around timing conversion between MIDI and dmusic. Right now MIDI files seem to be cut off before the end is reached.
Please have a look at the general approach in the meantime, I need to know if this is the right way to do this or not.
--
v27:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4982
--
v4: vkd3d: Support aliased tile binding if available.
vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for textures.
vkd3d: Implement ID3D12CommandQueue::UpdateTileMappings() for buffers.
vkd3d: Pre-bind sparse texture mip tails.
tests/d3d12: Add a test for freeing underlying memory of a reserved resource.
tests/d3d12: Add tests for UpdateTileMappings().
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/631
This only matches with digitizer devices for now, and its purpose is mainly to make testing possible with the virtual device on Wine, but could be ultimately useful for hidraw pointing devices, assuming we would support that in winebus / wineusb.
Later, it could also be extended to support mouse devices, but for now we use a different path with user drivers sending the hardware messages instead. Using a NT device for that has a lot of performance implications that will need to be resolved first, and it's unlikely the best way to do that. On the backend side, accessing the raw mouse devices usually requires privileges anyway.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5075