Sorry, I should have been more specific. I mean crossfading between them so that they are visible at the same time. I don't believe the example would be the same implementation. Right?
1 person found this helpful
I don't think we have a direct example of that. Basically, you would need to place the two images in DurationElements that overlap (through a combination of SerialElement and ParallelElement), e.g.:
DurationElement(ImageElement(Image #1), 10 seconds)
DurationElement(ImageElement(Image #2), 10 seconds)
After 8 seconds, the second image will appear. You would then need to apply the fade effect to each one. It might be possible to create a subclass of DurationElement to encapsulate the fade-in/fade-out logic, so that it would be automatically triggered when the DurationElement is triggered.
Would you recommend the same approach for video elements as well?
Yes, but instead of using a DurationElement, you can use a VideoElement directly (since VideoElement already has the notion of time, playability, etc.).
I have more or less the same requirement but with the exception that the fade is not time based but rather when they select (click) another media for display. In this case the duration has no meaning. It seems the issue I have is with the forced unload in set media on the MediaPlayer class. There's no way to play a fade effect when the second element is ready to play as the first element is forced to unload before the second has even started loading.
It seems the only option is to create my own MediaPlayer class, subclassing the MediaPlayer won't work because a call to super.media would excute the code I want to skip anyway
I've already created my MediaContainer to accomplish the transition as there was no means to do it with the current MediaContainer/Layout system. I'm starting to find this whole OSMF structure far more limiting than I do helpful.
If your requirement is to do a visual fade when switching between two different pieces of media, then it doesn't seem like you need to integrate with the MediaPlayer's MediaElement at all (i.e. don't incorporate the fade effect into the media composition that's assign to MediaPlayer.media).
The MediaPlayer drives the loading of the media element when you assign it to the media member. Are you saying to externalize all of the loading calls and only add it to the media player after the transition is complete? I can't see how that could work because you'd lose the ability to track things like bytes loaded through the MediaPlayer API.
I'd rather have it so when I add a media element to MediaPlayer it loads the new media item and when it's complete, and the state changes to Ready, it plays the transition and THEN unloads the old media item. I can accomplish this if I comment out the forced unload in MediaPlayer.media and leave it up to my custom MediaContainer to loadTrait.unload() and then remove the display object. I just hate having to hack API's because then I have to reapply the hack with each update.
EDIT: I can't even extend and implement my own media setter using a different name because all the methods called inside the media setter are private (mediaAtEnd, setState, updateTraitListeners etc). Grrr. All these private methods and internal classes are starting to drive me nuts.