#16571: APNG (Animated PNG) for animations
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: graphics | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/16571 | f4a242733b301b813f316d8661485b77ad520ee7
Dependencies: #16570, #16645 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by niles):
Replying to [comment:8 gagern]:
> Replying to [comment:7 niles]:
>
> I guess that in the long run, I might also add a method which I'd have
called `fallback` or `still`, which can be used to set the fallback image
to something other than the first frame. Would you prefer `set_still` or
`add_fallback` or something like this?
Let's use whatever term the APNG developers (Mozilla?) use for it . . .
>
> > * most of the `APngAssembler` methods are missing doctests.
>
> Mentioned that problem in comment:3. I can try to come up with some
doctests if you insist, but they'd be pretty ugly to read.
well, we have to have doctests . . . even if humans don't read them,
they're very useful in making sure that new code doesn't break old code.
When writing them, think "What is a machine-checkable way to ensure that
this method is producing what it claims to produce?" The current doctest
for `APngAssembler` is probably overkill. Also note that, if necessary,
you can use the `#indirect doctest` flag to mark doctests which check the
relevant method implicitly, but not explicitly.
>
> By the way, should I prepend a `_` to all my internal methods?
It's sort of a grey area . . . the key difference is that underscore
methods won't show up in the reference manual, for better or worse.
>
> > * Not sure if it's part of this ticket, but I really think
[http://git.sagemath.org/sage.git/commit/?id=a60fe0b14aa4094c86c5efb387f9fd5a9706a218
converting a generator to a list when rendering frames] is a bad idea.
When there are lots of very large frames, this becomes becomes time and
memory intensive. What advantage do you see?
>
> Quoting from the commit message of that commit: “The APNG pipeline
requires the number of frames up front”.
I see. I haven't checked to see why that's necessary . . . are you sure
it can't be avoided?
> I guess I could also save the *number* of frames, instead of the frames
themselves.
If you can do that without loading them all into memory, that would be
great
>
> An inferior alternative would be copying what `graphics_array()` does:
>
> {{{
> frame_list = list(self._frames)
> n = len(frame_list)
> }}}
>
> There you also have to maintain the list of all frames in memory,
although arguably only for the duration of the method call. What I
consider even more harmful, however, is the fact that the frames will be
generated multiple times.
right
> In my opinion, a generator should only be traversed once for the
workflow from construction to APNG output, and that one occurrence should
be when building the PNGs.
I fully agree. Ideally, this is done one item at a time, rather than
loading all frames into memory simultaneously.
--
Ticket URL: <http://trac.sagemath.org/ticket/16571#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
