stale

Looks like the problem is not limited to 'erase'. A newly drawn line also falls behind the view after certain zoom.

This is stupid, but I don't understand what to do.
There is a code and a video demonstrating it. The task looks easy and I am willing to do it if it isn't taken

Why can't we disable redo for an operation. We can introduce another flag for that and remove it from the undo stack whenever we go over it.This can be useful for things like adding images or other tasks which can't be redone(or can they?).

I couldn't figure out how to remove the blank image on pressing undo. Also I couldn't figure out how to disable the redo as it does nothing(same is the case for "Open Image").
@Julian Eisel (Severin) If you already did the undo properly or created a new operator type then do commit your patch. Otherwise I'll try to figure out how to fix the undo/redo problem.

@Julian Eisel (Severin), thanks :D . I'll try to fix the bug.

As mentioned in the previous comment, at the start of the animation/simulation the results are "acceptable". After repeating the simulation for different number of particles the result is that particle number 191 and no. 196 ALWAYS have almost twice the speed of the emitter. The value returned by evaluate_emitter_anim() is not very accurate. But I think this can work as a temporary solution and maybe a permanent one when the particles code is refactored.

Removed the previous code which used evaluate_emitter_anim(). Changed the time used by psys_get_birth_coords() from the whole frame-step time to time between last frame and birth time of the particle.

I don't understand why there would be a threading issue. We anyway call evaluate_emitter_anim() in reset_particle(). Why would it be an issue when evaluate_emitter_anim() is called in psys_get_birth_coords()?

By previous emitter state do you mean previous object state?
Also I tried changing the value of dtime, which I think is the correct thing to do, but there are precision errors of about 4%.
Also, storing the state makes the velocity dependent on frame step which may be undesirable.

How and where do I submit the diff file??

The problem seems to be in psys_get_birth_coords(). Correcting the dtime value sent through reset_particle() almost fixes the bug(Small variation between object and particle velocity)