QQuickTimeLine: add missing time checks

The same check is done in QQuickTimeLine::pause(), move() and moveBy(),
where the time is passed as an argument. QQuickTimeLine::accel() and
accelDistance() calculate the time based on velocity and acceleration
or distance. With tiny values this calculation can result to a negative
time due to integer overflow.

Task-number: QTBUG-35046
Change-Id: I000e73d3f787375946e8f87a5d24153ae919bc8d
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Merge pull request #3 from mbrasser-jolla/mer-stable

Use fuzzy comparison for another Flickable StopAtBounds case.
Merge pull request #4 from mbrasser-jolla/timeline-assert

QQuickTimeLine: add missing time checks
Squashed commit of the following:

commit 52b20d12a3593e776433c4f3ec1c6230755f1445
Author: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Date:   Fri Mar 14 15:15:26 2014 +0100

    Fix potential crash during shutdown for QQuickWindows

    The cleanup() function would deregister the render loop from all
    windows the render loop had seen, but the render loop doesn't see
    windows until the window gets a showEvent and for some implementations
    it was removed as a result of hideEvent. So add explicit tracking to
    QSGRenderLoop which is managed by QQuickWindow's constructor and
    destructor. With this, we no longer need the lists from the
    subclasses, so these functions are removed again.

    Change-Id: I05e5507ad57e23c80bacd99752654cc7d0890dc1
    Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>

    Conflicts:
    	src/quick/items/qquickwindow.cpp

commit 60bec30befb6468db79ab2acac6fcc7a389acca8
Author: Gunnar Sletta <gunnar.sletta@jollamobile.com>
Date:   Wed Mar 5 15:38:02 2014 +0100

    Make sure QSGRenderLoop is cleaned up cleanly.

    e13547c595913c58e6bd6a5ed80fdc729fae7d47 used a global static to clean
    up QSGRenderLoop which is triggered very late, potentially after
    SG backend API plugins have been unloaded. This results in crashes
    when used in combination with scenegraph-playgrounds's customcontext.

    Partially revert the change and instead clean up at the time of
    QApp::aboutToQuit and make sure we also disconnect cleanly from
    all QQuickWindows.

    This change also ensures that QSGRenderLoop::windowDestroyed() gets
    called for all QQuickWindows registered with the render loop. This
    ensures that rendering stops and that scene graph nodes and resources
    will be cleaned up regardless of whether the application has
    remembered to delete the window or not. This is a good thing as it
    makes the scene graph shutdown a bit cleaner.

    Change-Id: I9cb9093979f8eac05542f118a6ff9cfe5c84f745
    Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>

    Conflicts:
    	src/quick/items/qquickwindow.cpp
    	src/quick/scenegraph/qsgrenderloop.cpp
    	src/quick/scenegraph/qsgrenderloop_p.h

Change-Id: I14b60be55ed5fde72f38f48a79edc0b49f853a0c
Merge pull request #6 from sletta/next

[qtdeclarative] Fix crash on shutdown
MER: Fix memory corruption bug

(This patch can be removed when QTBUG-37834 is addressed upstream)

In QQmlData::destroyed(), release the compiledData after
destroying the context instead of before. The context
contains bindings which may contain references to the
compiledData. (At least with V4 bindings)

This might cause heap corruption in QV4Bindings::Binding::disconnect()
because it uses values from 'program' (one of the datas[] values
from a QQmlCompiledData) to possibly modify memory via sub->setActive().

The reads from a freed program are easily reproduced (just start
an app under lipstick and then close it; detected with valgrind).
I haven't witnessed any heap corruption from this but it may be
behind the occasional crashes of lipstick.
(cherry picked from commit 3cfbd9d3176cbbc95bdbe3712f4accdc1485ed55)
Revert "Squashed commit of the following:"

This reverts commit 69b5f133c52b0de0de3aba0bed6d727b5b3db00a.

This broke boosted applications.
Revert "Revert "Squashed commit of the following:""

This reverts commit 656155db64eeb770bd929338ef5416b96ca79a13.
Destroy render loop when QCoreApplication is cleaned up.

Doing it on 'aboutToQuit' meant we would clean it up whenever an
application ran QCoreApp::exec() which could be multiple times
per application run.

Change-Id: I59e06398a551ae7979e3832dff811937037fa106
Don't crash when render node doesn't have a batchroot

Change-Id: Ib8f70414eb477b4ec45097c8784a5fe1375cf012
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>

Conflicts:
	src/quick/scenegraph/coreapi/qsgbatchrenderer.cpp
Merge pull request #8 from sletta/rendernode-crash

[qtdeclarative] Don't crash when render node doesn't have a batchroot
Merge pull request #7 from sletta/next

[qtdeclarative] Revive previous revert and fix startup problems.
MER: Add systrace support.

Not upstreamable, just like the parent feature (systrace support) isn't.
QQuickPinchArea: Don't jump around when a finger is lifted.

Done-with: Martin Jones <martin.jones@jollamobile.com>
Build V4 with JIT, thanks to thumb.
Don't start continuing animation when it doesn't have children.

If we did, it would never stop.

Change-Id: Ie9d8f1731f6fa555f8dd6a56d6967a8f8f19a9f4
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Stop the animation driver when no animations are ticking.

When animations were registered we made a queued connection to
'startAnimations' to start the animation driver and also set the
'startAnimationPending' state to true. In 'stopTimer' we aborted
if 'startAnimationPending' was true, presumeably to avoid stopping
just to restart shortly after.

However, if an animation is registered which triggers the invoke
and then is immediately removed again, 'startAnimationPending' will
be true with no pending animations at the time of 'stopTimer'. As
a result, the driver would not stop and the system would continue
animating and trying to render.

Change-Id: Icbb01d7129c3a1bddef08a9f2a7aee957e3d2909
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Merge pull request #10 from sletta/runaway-animations

[qtdeclarative] Runaway animation fixes.
Fix memory corruption in XHR implementation

Now that the member data of Object is also on the GC heap, it is even more
important to call the base implementation of markObjects when re-implementing
it ;-)

Fixes also three XHR auto tests (text, cdata and stateChangeCallingContext)

Change-Id: Ifd033cac64a8cf27a9186d8cd9eb94369d8a60a5
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Fix marking of prototype objects in chain

With a real prototype chain it can happen that an internal class' prototype's
class itself has a prototype. Therefore the first transition on the empty class
is a PrototypeChange one, but the class the transition leads to may have
PrototypeChange transitions itself, which weren't marked.

There are multiple solutions to this, but this patch is the minimal fix by
recursing fully through the internal class tree. That way it's easier to
back-port the fix also into 5.2.x based branches.

Task-number: QTBUG-37834

Change-Id: I901b13a2663fbad5844003ca5752f2f304de320c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>

Conflicts:
	tests/auto/qml/qjsengine/tst_qjsengine.cpp