Render thread animations

We can run some animations on the rendering thread. Namely:

• opacity changes
• matrix changes (translate, scale, rotate, etc)
• shader uniform changes

The benefit of running animations on the render thread is that we can to a higher degree guarantee that animations run smootly even when the UI is spending time on the GUI thread.

There are two ways to implement this:

• Behind the scenes:
  • We silently move what we can to the render thread
  • good: It works out of the box, everyone benefits without any hassle.
  • bad: It easily breaks, for instance because code uses an additional property
  • bad: We don't want to send property updates back to the GUI thread for every frame (QMetaObject::invokeMethod()), so the property state only gets synced at the end. This makes bindings to said property behave "broken"
• New Animation API:
  • OpacityAnimator, ScaleAnimator, TranslateAnimator, RotationAnimatior (for instance)
  • good: Clear and explicit API means you get what you want when you want it.
  • bad: Requires people to understand the difference between XxxAnimator and XxxAnimation APIs
  • bad: Nobody benefits unless they use new API.

There are three separate layers that need to be implemented for this to work:

• The threaded render loop needs support for running without the GUI's involvement. Starting with 5.1, the threaded render loop can do this, but it currently does not run on windows. There is an example examples/quick/scenegraph/threadedanimation which shows how to use the current public API to run animations on the rendering thread.
• We should make use of this API inside our own Flickable so that panning is velvet.
• Public QML API for render thread animations.