proposal for animation: t=z to reference previous frames #3809
Comments
|
Seems reasonable at first blush, I would want to be able to specify As for escape code design will look into that in detail later, but seems I'll get to it when I have some time, or if you are eager you can submit |
|
Oh and while Oppenheimer certainly has a compelling visage as a lapsed theoretical physicist, I dont find him overly compelling :) |
|
excellent, i'm glad to hear you find it plausible. you're on 0.21.2 now, right? when do you see 0.21.3 happening? if not for a minute, i might try to knock it out, but no promises. no rush, obviously. thanks! |
|
There's no rush for 0.21.3 basically the only thing that needs a relative quick release is the synchronized update bug you reported, but since that bug has existed for years and no one ran into it until you did, its not that urgent. |
|
I have implemented this in master. Please check that it meets your |
|
<3 outstanding. i'm excited about this, and will write code against it no later than this week's end, and probably tonight. i will have unit tests around a fairly complex instance of it, so that'll serve as a second-order check. i'll do a one-off build where Notcurses engages this behavior for all kitty > 0.20.0 to test that it works, but in reality we'll be conditional on version >= 0.21.3 -- does that sound reasonable? and THANKS. with this change, the Kitty implementation of Notcurses will be lean and mean indeed, and fundamentally far out ahead of all other terminal bitmap implementations. you might have seen that i recently implemented deflate for the initial large transmission when using animation, and picked up a nice bandwidth win off that (once i thread frames out, it ought be an unconditional latency win for multiframe images as well). |
|
dankamongmen/notcurses#1900 addresses this feature from my side. |
|
On Thu, Jul 22, 2021 at 10:40:44AM -0700, nick black wrote:
<3 outstanding. i'm excited about this, and will write code against it no later than this week's end, and probably tonight. i will have unit tests around a fairly complex instance of it, so that'll serve as a second-order check. i'll do a one-off build where Notcurses engages this behavior for all kitty > 0.20.0 to test that it works, but in reality we'll be conditional on version >= 0.21.3 -- does that sound reasonable?
Yes, I plan on releasing this for 0.21.3
and THANKS. with this change, the Kitty implementation of Notcurses will be lean and mean indeed, and fundamentally far out ahead of all other terminal bitmap implementations. you might have seen that i recently implemented deflate for the initial large transmission when using animation, and picked up a nice bandwidth win off that (once i thread frames out, it ought be an unconditional latency win for multiframe images as well).
Glad to hear it.
|
|
alright, i've coded up an initial approach, and things aren't working as i expected. much too early to say whose bug it is, though. i'll continue to experiment, and give more useful results when i have them. |
|
Cool, like I said, I haven't really tested this functionality, beyond |
|
I fixed some errors of mine and now it's pretty much working; I have one remaining issue, but I believe it too to be my bug. I'll know within a few hours max. Looking really good, though. |
|
things seem to be working perfectly! |
|
On Sun, Jul 25, 2021 at 06:26:55PM -0700, nick black wrote:
things seem to be working perfectly!
Great, then it's ready for the next release.
|
yep, and i'll be supporting it out of the box. thanks! |
|
Cool, note that the kitty version is 0.22.0 not 0.21.3 (there were too many changes pending for a point release). |
|
i'll update to reflect that, thanks. it's possible that there's a bug when using composition on an image which has moved from its original position, but it might be my bug, just a heads-up. if it looks to be your issue, i'll of course file a new issue. |
Apologies if I've overlooked something in your docs/posts.
Use of the Kitty animation protocol has drastically reduced the necessary bandwidth for Notcurses's wipe+restore bitmap model (for those unaware, this refers to removing and then restoring cell-sized chunks). Unfortunately, my current implementation requires keeping a complete copy of the original RGBA data. I don't mind the memory consumption so much, but the copying is unfortunate.
This only really requires a single animation directive. I write the original image with a unique ID, and then:
\e_Ga=f,x=%d,y=%d,s=%d,v=%d,i=ID,X=1,r=1;",supplying either a 0-alpha cell-sized region (to wipe), or a copy of the original cell (to rebuild). i only ever have a single animation frame. life is good. i was able to reduce bandwidth by over 99.9%. but we can do better.
What i'd like to be able to do is rebuild using the data available, without keeping any more state myself. I believe you suggested replaying the wipes onto the base when I needed to rebuild, deleting the old current frame, and displaying the new frame. That requires me keeping a list of wipes, and playing them.
I'd like to transmit data for only part of the frame, but that data ought reference some other frame. I suggest (but am in no way married to) supporting
t=zin this context to indicate that the argument tof=is a frame id. the geometry is interpreted the same way -- a destination within the working frame. i would personally be satisfied with selecting a source to overlap with the destination, but if you want to be able to move the source region to some dest, you'd need two coordinates for the source (if these are supported, but not provided, the source origin ought be assumed to match the dest origin IMHO).so i would still only ever have two frames (and not 1+2, 1+3, 1+4 and so on, but 1+2 throughout). my rebuild operation would be wholly contained within the control block, referencing kitty-side data. my wipe operation would still be transmitted, but (a) i needn't keep state to generate 0s and (b) i can compress the hell out of a bunch of 0s. you needn't store anything that you're not already storing, and there's minimal churn in your own memories.
this operation effectively gets me O(1) time, O(1) state wipe+rebuild, and i try not to bug you for much, but that's too sweet not to go for =]. whaddya think?
Describe the solution you'd like
A clear and concise description of what you want to happen.
When sending an animation op with
a=f,t=zmeans i wish to use a previous frame as the new animation data, rather than supplying it inline or via the filesystem etc. in this case,f=Nwill be understood to reference frame N, which must exist. two new params may or may not be added to specify the origin on the referenced frame; either way, in the absence of such a specification, the source region is chosen to overlap the destination region. invalid origin specification for either the source or dest is an error.t=zwithoutf=Nis either an error, or a default to frame 1.It is undefined whether later cleanup of the referenced frame invalidates the derived frame (for my case, i'll only have two frames, so it shouldn't matter).
Describe alternatives you've considered
(1) Using mosaics (i.e. composing a larger graphic out of smaller ones), if granular to the cell level, there is no need for wiping nor restoring. I'd like to do this, but I've run into performance problems with all terminals with which I've tried it. I would need to keep the wipe+rebuild solution around, and I'd rather not have two paths. The animation protocol gets me almost all the way threre; this would effectively close the gap, while retaining one big graphic rather than hundreds.
(2) Using z-indices, there's less need for wipes-and-rebuilds, but they're sometimes still necessary if the image is not to be broken up (canonical example: partially transparent bitmap, some text underneath, some text atop, and all text has opaque backgrounds), and that decays to the mosaic case (I do intend to take advantage of z-indexing, as it's the only way to get text-above-graphic, but it's not a complete solution)
Even if there are other ways to get there, this seems a very low-cost (from a resources perspective -- I don't mean to presume it's insignificant work) addition; it seems to fit into the spec cleanly; it closes a conceptual hole in the protocol; this gets me mosaic-level capabilities without both of us having to track hundreds of cell-sized graphics.
Additional context
the power of j robert oppenheimer compels you!
The text was updated successfully, but these errors were encountered: