MediaPlayerElement - WinRT Xaml Island

[argumentum]

14 hours ago, WildByDesign said:

By the way, compiled binaries fail without <maxversiontested Id="10.0.18362.1"/>. So I ended up modifying AutoIt3Wrapper.au3 to include:

..we'll still need those *.manifest for testing the scripts w/o compiling.
Hopefully @Jon get's to compile the next AutoIt3 version with this in it.

[MattyD]

2 hours ago, MattyD said:

Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, System.Object>.  So registration is failing here.

Resolving the IID for this is a bit complex, and I'm close - but not there yet

Ok think I've cracked it.

To resolve the IID, I first need to modify some stuff in WinRT_MetaDataLocator (ATM metadatalocator is not correctly handling delegates),
Then,with _WinRT_GetParameterizedTypeInstanceIID:
Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, System.Object> should actually be passed as:
Windows.Foundation.TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, Object>

So long story short - At some point I'll modify _WinRT_CreateDelegate() so we have the ability to create a delegate of a certain "type".

I'm thinking something like:  

_WinRT_CreateDelegate("MediaOpen", "TypedEventHandler`2<Windows.Media.Playback.MediaPlayer, Object>")

or if we get that far, I might even generate some constants:

_WinRT_CreateDelegate("MediaOpen", $sIID_TypedEventHandler_2_MediaPlayer_Object)

Then it'll be a matter of  shuffling some internals so our delegate can respond to QI requests to its own IID, in addition to IUnknown.

Stay tuned...

[MattyD]

Ok here's the fruits of a couple more hours work.  I'll update post #1 once I'm reasonably happy with things, and eventually the main WinRT thread. - which admittedly has been a bit neglected of late...

MediaPlayer_2.zip

[Jos]

12 hours ago, MattyD said:

That's probably a question for @Jos. I'd say its unlikely to get up, but there's no harm in asking.

When it is a generic change we should make and works for all win10 compiled scripts, then obviously the change can be made.
Just give me the details of the change for the current Autoit3Wrapper.au3, and I will make those changes.  🙂 

Cheers,
Jos

[WildByDesign]

42 minutes ago, Jos said:

When it is a generic change we should make and works for all win10 compiled scripts, then obviously the change can be made.

So I guess the big question is whether or not this change could have any possible negative effects for any Win10 binaries.

And if so, is it worthwhile having a separate flag to enable it in the wrapper?

@MattyD I am not personally very familiar with WinRT stuff. But I feel like I’ve read somewhere before that different features could potentially have a different value required. Can you shed some light on this? Or would the maxversion value always remain the same?

[argumentum]

41 minutes ago, WildByDesign said:

So I guess the big question is whether or not this change could have any possible negative effects for any...

The manifest in my view is "I can do this and, I can do this and, I can do this and, ... "
So, you have a manifest that say "in can do it all", and you do what you can.
But at least you're not limited by the OS saying "oh no, you can't do that".

That's my take.

[Jos]

1 hour ago, WildByDesign said:

And if so, is it worthwhile having a separate flag to enable it in the wrapper?

I am fine with that too as long as it all makes sense and is useful for most.

[MattyD]

3 hours ago, WildByDesign said:

Can you shed some light on this? Or would the maxversion value always remain the same?

It seems like (for a win32 app) that the maxversiontested element really is just for XAML Islands, at least for now. From here:

Quote

This is intended to be used by desktop applications that use XAML Islands and that are not deployed in an MSIX package.

And it can appear multiple times - one for each version of windows that the app was "tested" on.

So does the version really matter? I don't know, but I don't think so.  Xaml islands only appeared in win10 1903 - so maybe maxversiontested exists to stop apps being run on win10 builds earlier than that. But that's obviously speculation.

The version must be 10.0.18362.0 or higher. (Win10 1903).  Also, windows can't predict the version numbers of future releases -  so if you set maxversiontested to a 20H2 build for example, you won't be able to run your app on 1903. (probably, as mentioned here)

so.. I guess if we're adding maxversiontested as a static value, 10.0.18362.0 probably makes the most sense.  Otherwise, if we have the ability to specify the value(s), it might be best to have the ability to specify multiple builds for back compatibility.

Edited 16 hours ago by MattyD
spelling

[WildByDesign]

I did some testing with various maxversiontested value. The original value that Matty suggested seems to be the best:

<maxversiontested Id="10.0.18362.1" />

So while it is called maxversiontested, it really seems to operate more like a minimum value. And in that sense, it seems very harmless and makes the most sense to keep it at the lower value as Matty already suggested.

It would be nice if it were possible to do a DllCall during process init to allow maxversiontested value similar to DPI scaling, but I don't believe it is possible.

I honestly don't think that it can cause any harm if it's compiled into every Win10 binary that AutoIt builds.

So, @Jos, whether you feel it should get compiled into any binary when the user opts for Win10 compatibility or if you think it should have some sort of separate flag to enable it is totally up to you. I am happy either way. As long as it's available in the AutoIt3Wrapper script, it will be beneficial. Thank you for your time, I appreciate it.

[WildByDesign]

@MattyD There is something that I find fascinating about this. When I do some type of script blocking, such as Sleep(10000) or keeping a MsgBox open for a duration of time, the video continues to play uninterrupted. This is a good thing, for sure.

But from a technical perspective I am curious, how is it doing that? Is the MediaPlayerElement working on a separate thread from the AutoIt process?

From what I can see, everything is in the same thread. I did see AppXSvc (AppX Deployment Service) start at the same time. But the process for that isn't using any CPU nor does it have any windows.