This is just nodes for now. The tests in the last patch may seem a bit overkill now, but it will be used for all the other prototypes, so they'll only need extra entries in the array/table, making it way simpler and less redundant.
--
v4: mshtml: Don't expose swapNode from NodePrototype.
mshtml: Don't expose replaceNode from NodePrototype.
mshtml: Don't expose removeNode from NodePrototype.
mshtml: Expose ownerDocument from NodePrototype.
mshtml/tests: Add initial tests for prototype chain props.
mshtml: Enumerate all own builtin props from host object's NextProperty.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6850
This is just nodes for now. The tests in the last patch may seem a bit overkill now, but it will be used for all the other prototypes, so they'll only need extra entries in the array/table, making it way simpler and less redundant.
--
v3: mshtml: Don't expose swapNode from NodePrototype.
mshtml: Don't expose replaceNode from NodePrototype.
mshtml: Don't expose removeNode from NodePrototype.
mshtml: Expose ownerDocument from NodePrototype.
mshtml/tests: Add initial tests for prototype chain props.
mshtml: Enumerate all own builtin props from host object's NextProperty.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6850
Does the new throttling mechanism introduce input lag? Testing with a simple SDL2 app polling for events, input delay is 9.8ms averaged over 100 clicks, but native application build is only 1.05ms. I implemented the mechanism used before with 200 message count and the input lag is only 1.2ms, but I suppose in real game there would be a big CPU usage spike
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5970#note_88177
Nikolay Sivov (@nsivov) commented about dlls/mf/evr.c:
> }
>
> if (SUCCEEDED(IMFTransform_ProcessInput(stream->parent->mixer, stream->id, sample, 0)))
> - IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_PROCESSINPUTNOTIFY, 0);
> + {
> + while (hr == S_OK && (hr = IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_PROCESSINPUTNOTIFY, 0)) == MF_E_TRANSFORM_TYPE_NOT_SET)
> + hr = IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_INVALIDATEMEDIATYPE, 0);
> + }
If it works like that, sure. But could we turn "hr == S_OK" to a loop break condition, after ProcessMessage. Or simply as "if ((hr == ProcessMessage()) != S_OK) break;. I think that would be more readable and easy to follow.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6059#note_88170
Streams hold a reference to the source, but this reference should not be taken until `Start()` is called because freeing the media source depends on release in `Shutdown()` of the stream's reference to the source. We could create the streams in `media_source_create()` and take source refs for them in `Start()`, but that's potentially confusing and fragile.
Streams can persist after the media source is destroyed. In that case, they cannot access the source object and it should be released and set to null. Windows behaviour is to release references to the source in `Shutdown()`. If we don't do this and a buggy app were to leak a stream object, the media source object would also leak and `wg_parser_destroy()` would not be called.
--
v5: winegstreamer: Release stream references to the media source in Shutdown().
https://gitlab.winehq.org/wine/wine/-/merge_requests/6783
On Wed Nov 20 10:02:28 2024 +0000, Huw Davies wrote:
> @bernhardu, I'd requested access to your repo so that I could make some
> cosmetic changes to the commit.
Hello Huw, sorry, did not realize this needs an action from my side, just confirmed it now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6787#note_88137
When source_enum_display_settings() fails to find a display mode because the index is out of range,
the index number in the log is always 0 because the same variable is decreased in the for loop to
find the display mode, giving the impression that it fails to find the first display mode.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6862