Page MenuHome

Grease Pencil Ctrl z bug
Closed, InvalidPublic


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.

Event Timeline

Ivam Pretti (ivampretti) raised the priority of this task from to Needs Triage by Developer.
Ivam Pretti (ivampretti) updated the task description. (Show Details)
Ivam Pretti (ivampretti) set Type to Bug.
Julian Eisel (Severin) reopened this task as Open.Dec 20 2014, 4:21 PM

eekk copied wrong task number, should be T42895... So this is still open

Julian Eisel (Severin) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Dec 20 2014, 8:41 PM

ubuntu 14.04 64bits NVIDIA Titan Black

hash: cefb764

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

@ronan ducluzeau (zeauro), yeah it only happens when using the arrow keys

I have a fix ready for this, but would like to check with @Joshua Leung (aligorith) before committing

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 rB8621c71c4c875a8e7e74fb2c3c66c0fd99c2c476

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).

Closing. Not a bug.

@Joshua Leung (aligorith), 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

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.