some frames skipped by prev/next frame on preview window

when using scrollbar on preview to seek previous or next rendered frame, some frames can not be located, take a look at the attached text file, preview it with fps=24, drop the scrollbar to the end, and start seek previous frame by clicking the left arrow of the scrollbar, you will find that 116 is next to the frame 118, 117 is skipped. and so on…

And it has been fixed in my new preview window ui layout implementation.
seek_pret_next_frame.sifz (627 Bytes)

oops, not exactly, when I turn the FPS to 12, the same problem appears in my implementation again.

It happens with 12 fps too. Opening your original file and doing a preview (default settings set to 0.5 and 12 fps) I can’t locate the frame at time 1s 2f. It jumps from 1s to 1s (again) and then to 1s 4f.
It seems that it is a round (int - double) math problem on the scroll/scale widget.

fixed in a weird way

void studio::Widget_Preview::next_frame()
        float rate = preview->get_fps();


void studio::Widget_Preview::prev_frame()
        float rate = preview->get_fps();

ok, maybe it is a good idea to take a close look at seek_frame in synfigapp folder :slight_smile:

Use same precision when possible: … b014102591
Good luck!

(hopefully) fixed in jcome_preview_window branch now.

Sadly I have a lot of boring things to do this week (paperwork, tax forms :cry: ), but at the weekend I’m hoping to finish the manual page for the Preview window so I’ll add a note in there.

Strangely, I just tried the file seek_pret_next_frame.sifz file out on my computer to write a note for the wiki and I don’t get this bug with Synfig 0.63.04 stable on a AMD A8-3820.

I noticed on my old 32-bit Intel computer that sometimes the Last Rendered would be one frame past the actual last rendered frame too, but that doesn’t happen on my new computer either.

Sometimes there are bugs related to floating point calculations that happens in one platform and not in other. Specially for 32 and 64 bits.

If it is set to 24.0 the prev/next buttons have correct behaviors.
Did you try other fps settings? 12.0 for example.

I fixed the issue by using frame number (int) instead of time (float/double), so we can be sure that it is gone now.