diff options
author | Jan Arve Saether <jan-arve.saether@qt.io> | 2016-11-18 10:11:58 +0100 |
---|---|---|
committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2016-11-20 21:09:40 +0000 |
commit | 567811a52ecbd4de312750ba7d7855e560a1d7af (patch) | |
tree | cbcd7b209753f77de6f558b12a0f862d16bd1b9b /src/quick/handlers/qquickpinchhandler.cpp | |
parent | 542eda976c2767ed6c1eecb4dbcbf838e0ca5a19 (diff) |
Remove QQuickMultiPointerHandler::startingCentroid
startingCentroid() used sceneGrabPos() in order to calculate the starting
centroid. Unfortunately, the starting centroid should not always be
calculated by the touch points initial grab position.
Consider the following:
1. Two touch points (P1 and P2) are pressed at position s1 and s2.
- Their sceneGrabPos() will return s1 and s1 respectively.
- startingCentroid() returns the point between s1 and s2.
2. The two touch points are moved to position m1 and m2.
- sceneGrabPos() will still return s1 and s1
- startingCentroid() returns the point between s1 and s2.
3. Touch point P1 is released, and then pressed again.
- P1->sceneGrabPos() returns m1
- P2->sceneGrabPos() returns s2
- startingCentroid() returns the point between m1 and s2, which
is not what we expect. It is expected that the startingCentroid then
would return the point between m1 and m2.
Because of this, startingCentroid cannot live up to its promise.
Good news is that implementations would just need to query the starting
centroid themselves by for instance querying touchPointCentroid() when the
handler becomes active.
Change-Id: I90fc23f2dd071998efab881cea9ba29b232cf118
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Diffstat (limited to 'src/quick/handlers/qquickpinchhandler.cpp')
0 files changed, 0 insertions, 0 deletions