Work is now more clearly split between the Android Main thread and the libGDX Rendering thread. As a quick overview:
The MediaPlayer is created and also released on the Android Main thread now
The shader and textures are now created across multiple frames (using a simple 'setupStep' state machine).
When calling play() before the MediaPlayer instance is created, the playback is queued for the next frame instead of blocking the render thread
Make frameAvailable volatile, so we can get away without synchronized in update.
This improves the 'felt' performance (less noticeable stutters) when loading and playing video on some weaker devices I tested.
Maybe this is enough to fix #32
For iOS ...
Playback no longer waits for the preroll to finish (which doesn't reliably happen from testing)
Instead, we wait for isReady AND the video resolution info to be loaded
Some functions are set to synchronized, as restarting a finished (looping) video may happen on any thread.
In general ...
The changes work with the assumptions:
that public VideoPlayer functions are only called on the libGDX Rendering Thread. (I think we can make this assumption similar to the rest of the libGDX World)
that callbacks may run on any Thread. (I added this to the documentation of the setListener functions)
For Android ...
Work is now more clearly split between the Android Main thread and the libGDX Rendering thread. As a quick overview:
play()before the MediaPlayer instance is created, the playback is queued for the next frame instead of blocking the render threadframeAvailablevolatile, so we can get away without synchronized inupdate.This improves the 'felt' performance (less noticeable stutters) when loading and playing video on some weaker devices I tested.
Maybe this is enough to fix #32
For iOS ...
In general ...
The changes work with the assumptions:
setListenerfunctions)