-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
we'll want NCBLIT_PIXEL plots, of course #1382
Comments
I've noticed the support you've been adding for Sixel and that's awesome but I thought Kitty used something different and that's what |
aye, and also ITerm2's 1337 https://nick-black.com/dankwiki/index.php?title=Notcurses#Pixel_blitters |
I noticed you added Windows Terminal to the list for Sixel support. It's not quite there yet though there's a working fork for it. I think a better method of its support is coming with being able to pass DCS sequences directly to the client app. |
I don't think this will be very difficult, and now that the z-axis work is coming together (#1388), I know how it'll look in e.g. |
including this in the 2.2.4 set, because we've just gotta have it in the demo. |
Alright, time to finally work on this! |
started some initial work in |
so the question really comes down to: do we draw the plot as one big bitmap, or do each cell as mosaics? this code is very much set up to be cell-based, but it's probably easier to draw as one big thing. hrmm.... |
i think when one considers the mechanics of wiping and restoring, what we're going to need here is a generator function in the plot code which spits out an RGBA frame using the appropriate data, which is then treated as a new frame of a multiframe, and encoded like normal using the associated TAM. that's definitely not going to be the fastest possible way, but anything else is madness, requiring deep integration between the encoding and plot layers. with that said, we can use a much smaller region for a pixel plot, due to the much greater resolution, so maybe it won't be so bad? |
we're close to the PoC level here now, after tonight's work. right now we ought be drawing an rgba area at cell granularity. that rgba needs be brought in as a multiframe (to preserve the TAM), and rendered to the target plane. |
we are now generating a (crap-filled) pixel plot in |
i do believe we have it. the first input supplied:
|
one more problem: since we're not rewriting all the cells, we end up with too large of values being printed in the legends (as we never scrub the leftmost columns). |
As
NCBLIT_PIXEL
becomes better integrated, we'll want to supply pixel-based plots. Plug it intonc[ud]plot
.The text was updated successfully, but these errors were encountered: