Onionskinning ignores changes in the timeline

[Tim Band]

Once you have captured an image, it becomes an onionskin (one frame of the blended or animated image you see in the capture window). The set of onionskins only changes if the camera is switched off and on (all are deleted), or if the number of frames to use is changed with the slider on the GUI.

On the contrary, the following should also cause changes:
(1) If a capture is undone, or the most recent capture deleted, the deleted image should cease to be an onionskin (and the one most recently ejected should be reinstated). Of course, redo should affect the set of onionskins too.
(2) If a new scene is begun, all onionskins should be deleted.
(3) If a different frame is made the active frame, that frame and the n-1 previous frames should become the onionskins.

In summary, the active frame plus the previous n-1 (as long as they are part of the same scene) should always be the onionskins, in the face of all operations such as adding and deleting scenes and frames, capturing new images, changing the active frame and using undo and redo.

[Raffaella Traniello (raffaella-traniello)]

I think deleting the set of onionskins if the camera is switched off and on is wrong.
During capture is pretty frequent to check the animation in progress with a playback of the captured frames. For this operation camera must be switched off.
After this playback check if you go back capturing (with camera switched on again) you'd want your full set of onionskins back.

[Herman Robak (herman-skolelinux)]

Tracing the execution flow of the Playback "mode" nearly broke my brain. What say you, Tim? Refactoring time?

[Tim Band (tim-band)]

Hi Herman- Are you talking about the new frame bar ideas? If so, we need a new bug report/feature request for that discussion. I have some ideas, but it looks hard. I see now why you are so keen on keeping the image file name constant throughout LSM's running time. This will allow us to rework observers so that they aren't so tied to the frame bar as it currently exists. Then we can actually change the frame bar.

This bug, on the other hand, is just a question of filling in the observer functions that exist. Of course, if we re-work observers, all this will be for nothing :-(

See my patch. It needs more testing.

It makes operation slower, so I don't think it is really an acceptable answer. I suppose we need background loading of images.

[Herman Robak (herman-skolelinux)]

No, my lament was not about the framebar, but LSM's current program flow for animation playback. I suppose it's the extra amount of mildly obfuscating observer pattern boilerplate that makes it hard to fit into my short term memory. And that grinds my gears.

Anyhow, we should brainstorm about the refactoring, elsewhere.

[Herman Robak (herman-skolelinux)]

From a quick skimming of the patch, it looks like insertions and deletions are expensive*, because the imageBuffer is a deque. imageBuffer is supposed to be fairly short, so why not use a linked list instead?

*) The same goes for sequences, that are vectors of Frame objects, by the way. But they may be much longer, so linked lists may not be the obvious choice there.

[Tim Band (tim-band)]

imageBuffer being short means that choice of container is irrelevant, given the other heavy processing going on. What I meant was that every time you choose a new frame, it has to load not only that image but all of its onionskins as well, so this seems unresponsive.

Ideally we should have a general framework for caching images that can be used by the frame bar as well as the frame view plus any other thing we think of.

I have written a stupid background image loading thing here that probably isn't too easy to turn into a general framework. But if you want to see how background image loading looks in this context, please give it a try.

I do think I'm pushing LSM further into the hole it's already in with this... but a fairly radical re-write is unavoidable soon anyway.

[Tim Band (tim-band)]

Oh dear, I can't seem to write today. What I mean is...

Without this patch, selecting different frames means loading a bunch of different onionskins before the new image can be displayed. With it, the image gets displayed and the onionskins appear as they are loaded, which makes it seem more responsive.

The re-write is of LSM itself, in order to support more useful framebars, and will involve changing the way images are stored on disk and allow caching. Maybe that's not so radical.

[Herman Robak (herman-skolelinux)]

Ok, I got it. Picking an "active frame" more than five frames before the last frame means you'd have to purge and reload the entire onion-skin buffer, and you don't want to block the display of the new active frame while that goes on, right?

I agree, the trailing images can re-appear leasurely in the course of a second. If they appear in order, it would even be a blingy effect. I also agree that we should not spend much time on implementing it before a major refactoring.

[Herman Robak (herman-skolelinux)]

My initial re-implementation of onionskinning in OpenGL does it very simple: The active frame is the "background" and the captured frame is the "foreground". This means the mixCount is only one, which is all you need for diff, but a bit limited for mix.

I'll push it soonish.

[Tim Band (tim-band)]

released in 0.8.0