Grease Pencil Ctrl z bug #42961

New Issue

Ivam Pretti · 2014-12-19T18:26:01+01:00

Ivam Pretti commented

2014-12-19 18:26:01 +01:00

System Information
Ubuntu 14.04, Intel onboard card

Blender Version 2.73 official test build
Reproduceable: YES
Crash of Blender:NO

Short description of error
when drawing with grease pencil and you press CTRL+z the frame changes to the last frame you used. Should stay on the frame you are working on.

Exact steps for others to reproduce the error
draw on frame 1, change the frame to for example 10, draw again, press CTRL+z, it goes back to frame 1.

System Information Ubuntu 14.04, Intel onboard card Blender Version 2.73 official test build Reproduceable: YES Crash of Blender:NO Short description of error when drawing with grease pencil and you press CTRL+z the frame changes to the last frame you used. Should stay on the frame you are working on. **Exact steps for others to reproduce the error** draw on frame 1, change the frame to for example 10, draw again, press CTRL+z, it goes back to frame 1.

Ivam Pretti commented

2014-12-19 18:26:01 +01:00

Changed status to: 'Open'

Ivam Pretti commented

2014-12-19 18:26:01 +01:00

Added subscriber: @ivampretti

blender-admin commented

2014-12-20 16:18:18 +01:00

This issue was referenced by 071ec918f4

This issue was referenced by 071ec918f4cd55b1615ba5acbdffc8e14c738cfe

Julian Eisel commented

2014-12-20 16:19:50 +01:00

Changed status from 'Open' to: 'Resolved'

Julian Eisel closed this issue

2014-12-20 16:19:50 +01:00

Julian Eisel commented

2014-12-20 16:19:50 +01:00

Closed by commit 071ec918f4.

Closed by commit 071ec918f4.

Julian Eisel commented

2014-12-20 16:21:26 +01:00

Changed status from 'Resolved' to: 'Open'

Julian Eisel reopened this issue

2014-12-20 16:21:26 +01:00

Julian Eisel commented

2014-12-20 16:21:26 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2014-12-20 16:21:26 +01:00

eekk copied wrong task number, should be blender/blender-addons#42895... So this is still open

Michael Pollind commented

2014-12-22 07:24:50 +01:00

Added subscriber: @pollend

Michael Pollind commented

2014-12-22 07:24:55 +01:00

Removed subscriber: @pollend

Joshua Leung was assigned by Sergey Sharybin

2014-12-22 10:10:37 +01:00

Sergey Sharybin commented

2014-12-22 10:10:37 +01:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-12-22 10:10:37 +01:00

Joshua, do you mind having a look here?

Joshua Leung was unassigned by Julian Eisel

2014-12-29 19:11:22 +01:00

Julian Eisel self-assigned this 2014-12-29 19:11:22 +01:00

Julian Eisel commented

2014-12-29 19:11:22 +01:00

Added subscriber: @JoshuaLeung

ronan ducluzeau commented

2014-12-30 18:06:09 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2014-12-30 18:06:09 +01:00

ubuntu 14.04 64bits NVIDIA Titan Black

hash: cefb764

I cannot reproduce.
Ctrl Z does not change frame for me.

ubuntu 14.04 64bits NVIDIA Titan Black hash: cefb764 I cannot reproduce. Ctrl Z does not change frame for me.

Julian Eisel commented

2014-12-30 18:27:39 +01:00

@zeauro, yeah it only happens when using the arrow keys

I have a fix ready for this, but would like to check with @JoshuaLeung before committing

@zeauro, yeah it only happens when using the arrow keys I have a fix ready for this, but would like to check with @JoshuaLeung before committing

Joshua Leung commented

2014-12-31 00:43:27 +01:00

Indeed, this seems to be something that only happens when using the arrow keys and not when dragging the time slider. In that case, it's not a bug, but rather, something done by design (or rather, as a compromise). See 8621c71c4c

The rationale for this is something like this:

If we put undo on the arrow key frame change, there is the very real risk that an animator using the arrow keys to flip between two keyframes (i.e. equivalent of "rolling" frames in 2D animation) or of using the arrow keys to step through the animation (i.e. either by holding down the key and letting auto-repeat do its thing, or by repeatedly stabbing it quickly) will quickly fill up the undo buffer. We're not talking about just 2-3 undo events here, but more on the order of 100's of them.

There is no way to tell the difference between an operator being called multiple times as the key was held down or pummelled rapidly, vs the operator was purposefully executed to yield an undoable reference point/state. At least not within the event handling system we have in place.

Scrubbing the timeline (i.e. holding down the mouse and dragging), or purposefully clicking and setting the time somewhere else are a different matter. For the scrubbing case, an animator can scrub around for a long time, checking the animation, at different speeds and in forward/reverse order, etc. but in the end, only a single undo push gets added. For the purposeful click, we definitely know that it was a unique and intended operation that the animator wishes to have respected - subsequent operations should not skip past it, and it should be able to be undone.

Admittedly, it is not the most ideal situation, and some cases like this still happen. But as the "simplest" solution, this is not that bad either.

EDIT: Now, if we really did have to make the arrow keys case also work, we'd have to resort to doing crazy things like making the screen.frame_offset operator modal. Its event flow would look something like:

invoke()
- Change frame by the amount requested
- Start time-out timer (say, 500ms)
- Start modal op
modal()
- if left/right arrow:
  - Perform frame change in the requested direction
  - Reset/restart timer
- else (other key, or time-up)
  - Exit operator
exec()
- Only perform the frame change requested (i.e. the one that would be initially done when calling invoke())

Now, doing something like this is probably overkill, but is something we could consider if it really was that much of an issue (which I don't think it is).

Indeed, this seems to be something that only happens when using the arrow keys and not when dragging the time slider. In that case, it's not a bug, but rather, something done by design (or rather, as a compromise). See 8621c71c4c The rationale for this is something like this: * If we put undo on the arrow key frame change, there is the very real risk that an animator using the arrow keys to flip between two keyframes (i.e. equivalent of "rolling" frames in 2D animation) or of using the arrow keys to step through the animation (i.e. either by holding down the key and letting auto-repeat do its thing, or by repeatedly stabbing it quickly) will quickly fill up the undo buffer. We're not talking about just 2-3 undo events here, but more on the order of 100's of them. There is no way to tell the difference between an operator being called multiple times as the key was held down or pummelled rapidly, vs the operator was purposefully executed to yield an undoable reference point/state. At least not within the event handling system we have in place. * Scrubbing the timeline (i.e. holding down the mouse and dragging), or purposefully clicking and setting the time somewhere else are a different matter. For the scrubbing case, an animator can scrub around for a long time, checking the animation, at different speeds and in forward/reverse order, etc. but in the end, only a single undo push gets added. For the purposeful click, we definitely know that it was a unique and intended operation that the animator wishes to have respected - subsequent operations should not skip past it, and it should be able to be undone. Admittedly, it is not the most ideal situation, and some cases like this still happen. But as the "simplest" solution, this is not that bad either. --- EDIT: Now, if we really did have to make the arrow keys case also work, we'd have to resort to doing crazy things like making the screen.frame_offset operator modal. Its event flow would look something like: * **invoke()** * Change frame by the amount requested * Start time-out timer (say, 500ms) * Start modal op * **modal()** * if left/right arrow: * Perform frame change in the requested direction * Reset/restart timer * else (other key, or time-up) * Exit operator * **exec()** * Only perform the frame change requested (i.e. the one that would be initially done when calling invoke()) Now, doing something like this is probably overkill, but is something we could consider if it really was that much of an issue (which I don't think it is).

Joshua Leung commented

2014-12-31 00:44:06 +01:00

Changed status from 'Open' to: 'Archived'

Joshua Leung closed this issue

2014-12-31 00:44:06 +01:00

Joshua Leung commented

2014-12-31 00:44:06 +01:00

Closing. Not a bug.

Julian Eisel commented

2014-12-31 01:53:10 +01:00

@JoshuaLeung, I agree, that's why I wanted to check with you before committing...

I think your proposal would be fine, but I'd rather call the frame change from modal(), as animators might want to search a specific frame or want to slowly scrub through the frames, one by one.
Without implementing your proposal, I'm afraid we'd get more reports on that, so I think it would be worth investigating

@JoshuaLeung, I agree, that's why I wanted to check with you before committing... I think your proposal would be fine, but I'd rather call the frame change from modal(), as animators might want to search a specific frame or want to slowly scrub through the frames, one by one. Without implementing your proposal, I'm afraid we'd get more reports on that, so I think it would be worth investigating

Ivam Pretti commented

2014-12-31 20:28:13 +01:00

I just think that if you draw and made a mistake, you should be able to press Ctrl+Z and undo only the thing you draw even moving the timeline with the arrow keys. Because its more precise move frame by frame with the arrow keys than an slider. And most of the time we just move about 2 or 3 frames, not 50. And every time its moved to a frame to draw again you should move to the same frame again its a waste of time.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Grease Pencil Ctrl z bug #42961