Commit: 3b75d6c4f9a60258b40ead78533dfd219cfc85ce
Author: Joshua Leung
Date: Fri Apr 25 13:32:27 2014 +1200
https://developer.blender.org/rB3b75d6c4f9a60258b40ead78533dfd219cfc85ce
Fix T39880: Cancelling transforms in Graph Editor does not restore F-Curves to
original state
Since autosnap was being applied during the flushing step for various practical
reasons,
it wasn't possible to restore keyframes and handles to their original values,
as these
would always get overwritten before getting a chance to be written back to the
keyframes.
===================================================================
M source/blender/editors/transform/transform_conversions.c
M source/blender/editors/transform/transform_generics.c
===================================================================
diff --git a/source/blender/editors/transform/transform_conversions.c
b/source/blender/editors/transform/transform_conversions.c
index 8830b02..2ac92ce 100644
--- a/source/blender/editors/transform/transform_conversions.c
+++ b/source/blender/editors/transform/transform_conversions.c
@@ -4107,8 +4107,9 @@ void flushTransGraphData(TransInfo *t)
/* handle snapping for time values
* - we should still be in NLA-mapping timespace
* - only apply to keyframes (but never to handles)
+ * - don't do this when cancelling, or else these changes
won't go away
*/
- if ((td->flag & TD_NOTIMESNAP) == 0) {
+ if ((t->state != TRANS_CANCEL) && (td->flag & TD_NOTIMESNAP) ==
0) {
switch (sipo->autosnap) {
case SACTSNAP_FRAME: /* snap to nearest frame */
td2d->loc[0] =
floor((double)td2d->loc[0] + 0.5);
@@ -4136,8 +4137,11 @@ void flushTransGraphData(TransInfo *t)
*
* NOTE: We also have to apply to td->loc, as that's what the
handle-adjustment step below looks
* to, otherwise we get "swimming handles"
+ * NOTE: We don't do this when cancelling transforms, or else
these changes don't go away
*/
- if ((td->flag & TD_NOTIMESNAP) == 0 && ELEM(sipo->autosnap,
SACTSNAP_STEP, SACTSNAP_TSTEP)) {
+ if ((t->state != TRANS_CANCEL) && (td->flag & TD_NOTIMESNAP) ==
0 &&
+ ELEM(sipo->autosnap, SACTSNAP_STEP, SACTSNAP_TSTEP))
+ {
switch (sipo->autosnap) {
case SACTSNAP_STEP: /* frame step */
td2d->loc2d[0] =
floor((double)td2d->loc[0] + 0.5);
diff --git a/source/blender/editors/transform/transform_generics.c
b/source/blender/editors/transform/transform_generics.c
index ccb7e13..ee8a851 100644
--- a/source/blender/editors/transform/transform_generics.c
+++ b/source/blender/editors/transform/transform_generics.c
@@ -529,41 +529,45 @@ static void recalcData_nla(TransInfo *t)
break;
}
- /* handle auto-snapping */
- switch (snla->autosnap) {
- case SACTSNAP_FRAME: /* snap to nearest frame */
- case SACTSNAP_STEP: /* frame step - this is basically
the same, since we don't have any remapping going on */
- {
- tdn->h1[0] = floorf(tdn->h1[0] + 0.5f);
- tdn->h2[0] = floorf(tdn->h2[0] + 0.5f);
- break;
- }
-
- case SACTSNAP_SECOND: /* snap to nearest second */
- case SACTSNAP_TSTEP: /* second step - this is basically
the same, since we don't have any remapping going on */
- {
- /* This case behaves differently from the rest,
since lengths of strips
- * may not be multiples of a second. If we just
naively resize adjust
- * the handles, things may not work correctly.
Instead, we only snap
- * the first handle, and move the other to fit.
- *
- * FIXME: we do run into problems here when
user attempts to negatively
- * scale the strip, as it then just
compresses down and refuses
- * to expand out the other end.
- */
- float h1_new =
(float)(floor(((double)tdn->h1[0] / secf) + 0.5) * secf);
- float delta = h1_new - tdn->h1[0];
+ /* handle auto-snapping
+ * NOTE: only do this when transform is still running, or we
can't restore
+ */
+ if (t->state != TRANS_CANCEL) {
+ switch (snla->autosnap) {
+ case SACTSNAP_FRAME: /* snap to nearest frame */
+ case SACTSNAP_STEP: /* frame step - this is
basically the same, since we don't have any remapping going on */
+ {
+ tdn->h1[0] = floorf(tdn->h1[0] + 0.5f);
+ tdn->h2[0] = floorf(tdn->h2[0] + 0.5f);
+ break;
+ }
- tdn->h1[0] = h1_new;
- tdn->h2[0] += delta;
- break;
- }
-
- case SACTSNAP_MARKER: /* snap to nearest marker */
- {
- tdn->h1[0] =
(float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h1[0]);
- tdn->h2[0] =
(float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h2[0]);
- break;
+ case SACTSNAP_SECOND: /* snap to nearest second
*/
+ case SACTSNAP_TSTEP: /* second step - this is
basically the same, since we don't have any remapping going on */
+ {
+ /* This case behaves differently from
the rest, since lengths of strips
+ * may not be multiples of a second. If
we just naively resize adjust
+ * the handles, things may not work
correctly. Instead, we only snap
+ * the first handle, and move the other
to fit.
+ *
+ * FIXME: we do run into problems here
when user attempts to negatively
+ * scale the strip, as it then
just compresses down and refuses
+ * to expand out the other end.
+ */
+ float h1_new =
(float)(floor(((double)tdn->h1[0] / secf) + 0.5) * secf);
+ float delta = h1_new - tdn->h1[0];
+
+ tdn->h1[0] = h1_new;
+ tdn->h2[0] += delta;
+ break;
+ }
+
+ case SACTSNAP_MARKER: /* snap to nearest marker
*/
+ {
+ tdn->h1[0] =
(float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h1[0]);
+ tdn->h2[0] =
(float)ED_markers_find_nearest_marker_time(&t->scene->markers, tdn->h2[0]);
+ break;
+ }
}
}
_______________________________________________
Bf-blender-cvs mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
