In the course of stunting on https://github.com/hpjansson/chafa/issues/27, I discovered that chafa 1.8.0 renders AllRGB/balloon.jpg in about half the time of ncplayer on my 3970X. Representative timings:

[schwarzgerat](0) $ time chafa /media/chungus/images/allrgb/balloon.png  -f sixel > /dev/null

real    0m0.420s
user    0m0.744s
sys     0m0.057s
[schwarzgerat](0) $ 

vs

[schwarzgerat](0) $ time ~/src/dankamongmen/notcurses/build-3.0.5/ncplayer /media/chungus/images/allrgb/balloon.png  -sscale -k > /dev/null

real    0m0.774s
user    0m0.720s
sys     0m0.053s
[schwarzgerat](0) $ 

in addition, the chafa output is slightly better -- look at the purple sections, and their borders with the blue sections to their right. we have some weird green pixels in there, unlike chafa.

ncplayer:

chafa:

note that this is on amd64, where chafa AFAIK uses hand-coded SIMD. i'm not sure if that's true on other architectures, but who cares; i tolerate defeat on no platform. well, i suppose there's only one thing to do now.

THERE CAN BE ONLY ONE

@dnkl pointed this out in #1380, but it's worth its own issue. Get two xterms up, along with a recent mpv build featuring libsixel support. Run it alongside ncplayer -bpixel. mpv's superiority is obvious (we beat it with cell output, though). Get to this level of output, in both speed and quality.

@edmonds thinks it would be a good idea to split out a libnotcurses1 package sans ffmpeg linkage. I'm inclined to agree, though I think we differ a little on exactly how we'd like to see it done. This is not a blocker for uploading and sponsorship.

with quantanal improved in #2502, we're now seeing divergence on a more complex, but still simple, image:

[schwarzgerat](0) $ ./quantanal ../data/chunli23.png
analyzing ../data/chunli23.png...
 source pixels: 99x46
 rendered: 99x46 18216B
 control sequence: 3134 bytes (17.2%)
 00004554 pixels analyzed Δr 318498 Δg 3546 Δb 3600
 Colors: 17 vs 27
 4554px Δr 318498 (69.9) Δg 3546 (0.779) Δb 3600 (0.791)
 avg diff per pixel: 71.5
done with ../data/chunli23.png.
[schwarzgerat](0) $

we're for some reason using 10 more colors, and missing by a wide 71.5 per. adding NOINTERPOLATION makes things worse:

[schwarzgerat](0) $ ./quantanal ../data/chunli23.png
analyzing ../data/chunli23.png...
 source pixels: 99x46
 rendered: 99x46 18216B
 control sequence: 3134 bytes (17.2%)
 00004554 pixels analyzed Δr 315107 Δg 5968 Δb 3489
 Colors: 17 vs 97
 4554px Δr 315107 (69.2) Δg 5968 (1.31) Δb 3489 (0.766)
 avg diff per pixel: 71.3
done with ../data/chunli23.png.
[schwarzgerat](0) $

meanwhile, on another, we drastically reduce the number of colors:

[schwarzgerat](0) $ ./quantanal ../data/worldmap.png
analyzing ../data/worldmap.png...
 source pixels: 475x860
 rendered: 475x860 1634000B
 control sequence: 130695 bytes (7.998%)
 00408500 pixels analyzed Δr 828526 Δg 899641 Δb 877151
 Colors: 233 vs 43
 408500px Δr 828526 (2.03) Δg 899641 (2.2) Δb 877151 (2.15)
 avg diff per pixel: 6.38
done with ../data/worldmap.png.
[schwarzgerat](0) $

In a Kantian sense, it would seem a good thing if notcurses worked on windows, for whatever definition of works that means. I very much doubt that I will ever undertake this work, but if some brave soul wishes to take a stab at it, or report problems, or whatever, here's a bug in which you might do that.

Run e.g. grid or any other CLI-style program that has no text output. There will be a blank line before the new prompt. Running e.g. true or other such tools results in no such blank line, and we oughtn't either.

As far as Wiki's concerned, UTF-8 can be unambiguously parsed without any sort of termination. Why there must be a termination character at the end of wchar_t*?

I have a status line in my application that can be used to display an overview of all keyboard shortcuts. The status line has a default background color and is in a separate plane. Initially, the status line is drawn correctly with the right background and foreground color. When the user presses '?', the status line will print some application shortcut descriptions.

I notice that when I suppress notcurses banners using NCOPTION_SUPPRESS_BANNER, when the help is displayed in the status line, the text is not printed with the background color for the status line plane:

Initial view (the gray line is the status bar of the application, the rest is tmux):

After pressing '?' without NCOPTION_SUPPRESS_BANNER:

After pressing '?' with NCOPTION_SUPPRESS_BANNER:

The following program reproduces the problem:

#include <locale.h>
#include <notcurses/notcurses.h>
#include <stdlib.h>

static struct ncplane *make_status_line_plane(struct ncplane *std_plane) {
  struct ncplane_options opts = {0};
  opts.rows = 1;
  opts.cols = ncplane_dim_x(std_plane);
  opts.y = ncplane_dim_y(std_plane) - 1;
  opts.x = 0;

  nccell c = CELL_CHAR_INITIALIZER(' ');
  cell_set_bg_rgb8(&c, 0x20, 0x20, 0x20);

  struct ncplane *status_line_plane = ncplane_create(std_plane, &opts);
  ncplane_set_base_cell(status_line_plane, &c);
  return status_line_plane;
}

static void print_status_line(struct ncplane *plane) {
  ncplane_putstr_aligned(plane, 0, NCALIGN_LEFT, " ?: help");
}

static void print_help(struct ncplane *plane) {
  const int width = ncplane_dim_x(plane);
  ncplane_erase(plane);
  ncplane_putstr_aligned(
      plane, 0, NCALIGN_LEFT,
      " j/k: scroll up/down   C-B/C-F: page up/down   q: quit");
  ncplane_putstr_aligned(plane, 0, NCALIGN_RIGHT,
                         "press any key to close help ");
}

int main(int argc, char **argv) {
  setlocale(LC_ALL, "");

  notcurses_options opts = {0};
  opts.flags = NCOPTION_SUPPRESS_BANNERS;

  struct notcurses *nc;
  if ((nc = notcurses_core_init(&opts, NULL)) == NULL) {
    return EXIT_FAILURE;
  }

  struct ncplane *std_plane = notcurses_stdplane(nc);
  struct ncplane *status_line_plane = make_status_line_plane(std_plane);

  ncplane_move_top(status_line_plane);

  struct ncinput input = {0};
  bool quit = false;
  while (!quit) {
    print_status_line(status_line_plane);
    notcurses_render(nc);
    notcurses_getc_blocking(nc, &input);
    switch (input.id) {
    case '?':
      print_help(status_line_plane);
      notcurses_render(nc);
      notcurses_getc_blocking(nc, &input);
      ncplane_erase(status_line_plane);
      break;
    case 'q':
      quit = true;
      break;
    }
  }

  notcurses_stop(nc);
}

Is this an issue in the program above, or maybe a bug in notcurses itself?

I am using notcurses 2.1.7. My terminal is st 0.8.4. Ouput from export | egrep 'LANG|LC_CTYPE|TERM':

LANG=en_US.UTF-8
TERM=tmux-256color
TERMINAL=st
TERMINFO=/home/ton/.local/share/terminfo

We have two automata we traverse to handle control escapes -- the one handled by pump_control_read(), and the special key trie. as a result, we have two distinct control loops, and two distinct states. this last is horrible, as there's no well-defined map of state changes effected by one on the other.

unite these two automata. given that special keys require a dynamic state machine (it's prepared based on terminfo data), a wholly explicit controlflow-based automaton (like that used in pump_control_read()) won't work. we need a dataflow-based one, as used by our trie traversal.

so we'll need add some special node types to our trie, basically the same we have from the other automaton:

• accumulate a number
• accumulate a string
• accumulate a hex-encoded string, which is just a special case of either of the previous 2 ...and that's it, i think? pretty easy. let's do it up right

Currently, if we interrogate a terminal, and don't get a response, the program will simply hang. Hence the requirement that the user explicitly call some function (e.g. notcurses_check_pixel_support()) before we begin interrogation.

I hate this so fucking much. I have no idea whether user input can break up the terminal response, but it wouldn't surprise me at all (and if it doesn't break the response, we'll at best lose said input). Hate hate hate hate hate.

I've been unwilling to put in a timeout, because on a loaded system, a slow reply is totally normal, and what timeout would we use, and even worse would be pushing that timeout question to the user, because they know nothing. I stand by this decision, because I am a dinosaur and a curmudgeon and everyone's too busy these days. Let the computer cogitate, if that's what it needs to do.

I do think, however, that we need at least print a diagnostic after a certain time goes by without a response, so the user isn't just left with no idea what's up. I think this can be dumped to stderr; it'll be jarring and disrupt any drawn screen, but hey, you've been sitting around for five (or whatver) stimulus-free seconds already, and in all likelihood you'll be sitting there until time ends or the power fails.

So yeah, make a concession to reality, and after say 5 seconds without a response from the terminal, print a diagnostic to stderr about "N seconds without a response from the terminal....". Maybe include the TERM value in this output for the inevitable bug reports.

Better yet would be a method to break user input up from terminal responses, but I doubt that this is possible =[. Maybe we ought take unrecognized input and queue it up as user input, but then we're just forwards-incompatible with new, wacky returns from tomorrow's terminals.

Fuck the world, save yourself.

I haven't tested with a specific version of notcurses, but I've seen in the code that you set private mode 80 when you initialize sixel: https://github.com/dankamongmen/notcurses/blob/3dbb3c149d2dafa57f51bcaa96a54176a4cd66d1/src/lib/sixel.c#L871

There is some confusion as to whether DECSDM is intended to enable sixel scrolling or disable it, and around half the terminals I've tested have implemented it one way, and half the other. On terminals that interpret mode 80 as a request to to disable sixel scrolling, your sixel images are going to be rendered in the wrong place.

For the record, I think you are using it is the wrong way, but considering how terminals are currently split on this issue, there really isn't a right way. The best course of action is to leave that mode alone. Every terminal I've tested does at least have sixel scrolling enabled by default, so unless you actually need to disable scrolling, there should be no reason to change the mode.

I follow installation instructions... when running the tests it freezes up on test one... I am able to run make install and make demo... I get a blank output until i enter cmd+D on my keyboard and am put back into my terminal... any advice would be appreciated.

this is the output of the test

Running with LANG=C.UTF-8
Running with TERM=xterm-256color```

THANKS!

Attempting to build against recent (git checkout) ffmpeg hits:

[ 20%] Building C object CMakeFiles/notcurses.dir/src/media/ffmpeg.c.o
/home/dank/src/dankamongmen/notcurses/src/media/ffmpeg.c: In function ‘ffmpeg_stream’:
/home/dank/src/dankamongmen/notcurses/src/media/ffmpeg.c:523:5: warning: ‘pkt_duration’ is deprecated [-Wdeprecated-declarations]
  523 |     uint64_t duration = ncv->details->frame->pkt_duration * tbase * NANOSECS_IN_SEC;
      |     ^~~~~~~~
In file included from /home/dank/src/dankamongmen/notcurses/src/media/ffmpeg.c:4:
/usr/local/include/libavutil/frame.h:617:13: note: declared here
  617 |     int64_t pkt_duration;
      |             ^~~~~~~~~~~~

Environment:

• OS: Centos 7.9
• notcurses version: 3.0.8
• GCC: 4.8.5

compile from source code by issuing the command cmake ../ -DUSE_GPM=on -DUSE_QRCODEGEN=on -DBUILD_TESTING=off -DUSE_DOCTEST=off -DUSE_MULTIMEDIA=none, then throw errors as below:

-- Checking for one of the modules 'tinfo>=6.1;ncursesw>=6.1'
CMake Error at /usr/local/share/cmake-3.23/Modules/FindPkgConfig.cmake:890 (message):
  None of the required 'tinfo>=6.1;ncursesw>=6.1' found
Call Stack (most recent call first):
  CMakeLists.txt:104 (pkg_search_module)

Besides, I have built and installed the latest ncurses library with version 6.3, and I have did lots of google search for tinfo, but no any clues found, so how to install tinfo with version required? and I found the library file 【/usr/lib/libncursesw.so.6.3】already exists, so why it still report that ncursesw >= 6.1 ? any help will be appreciated.

While trying to build libs using mingw, i get the error below. I used following cmake options: USE_DOCTEST=off USE_PANDOC=off BUILD_EXECUTABLES=off USE_MULTIMEDIA=oiio. Using ffmpeg instead of OpenImageIO helps, but perfomance is bad and the demo breaks after the penguin scene.

[109/112] Linking CXX shared library libnotcurses.dll
FAILED: libnotcurses.dll libnotcurses.dll.a
cmd.exe /C "cd . && C:\msys64\ucrt64\bin\c++.exe -O2 -g -DNDEBUG   -shared -o libnotcurses.dll -Wl,--out-implib,libnotcurses.dll.a -Wl,--major-image-version,3,--minor-image-version,0 CMakeFiles/notcurses.dir/src/media/ffmpeg.c.obj CMakeFiles/notcurses.dir/src/media/none.c.obj CMakeFiles/notcurses.dir/src/media/oiio-indep.c.obj CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj CMakeFiles/notcurses.dir/src/media/shim.c.obj CMakeFiles/notcurses.dir/src/compat/compat.c.obj -L/usr/local/lib libnotcurses-core.dll.a  -lOpenImageIO  -lwsock32  -lws2_32  -lsecur32  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> >::size() const':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_vector.h:988: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValueaSERKS0_'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `void std::_Destroy_aux<false>::__destroy<__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > > >(__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, __gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `OpenImageIO_v2_4_5::ParamValue* std::__copy_move<false, false, std::random_access_iterator_tag>::__copy_m<OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*>(OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_algobase.h:383: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValueaSERKS0_'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `OpenImageIO_v2_4_5::ParamValue* std::__do_uninit_copy<OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*>(OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_uninitialized.h:119: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue12init_noclearENS_7ustringENS_8TypeDescEiNS0_6InterpEPKvNS0_4CopyENS0_11FromUstringE'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `OpenImageIO_v2_4_5::ParamValue* std::__do_uninit_copy<__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, OpenImageIO_v2_4_5::ParamValue*>(__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, __gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, OpenImageIO_v2_4_5::ParamValue*)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_uninitialized.h:116: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue12init_noclearENS_7ustringENS_8TypeDescEiNS0_6InterpEPKvNS0_4CopyENS0_11FromUstringE'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `void std::_Destroy_aux<false>::__destroy<OpenImageIO_v2_4_5::ParamValue*>(OpenImageIO_v2_4_5::ParamValue*, OpenImageIO_v2_4_5::ParamValue*)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv'
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj:C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_construct.h:162: more undefined references to `__imp__ZN18OpenImageIO_v2_4_510ParamValue11clear_valueEv' follow
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/notcurses.dir/src/media/oiio.cpp.obj: in function `OpenImageIO_v2_4_5::ParamValue* std::uninitialized_copy<__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, OpenImageIO_v2_4_5::ParamValue*>(__gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, __gnu_cxx::__normal_iterator<OpenImageIO_v2_4_5::ParamValue const*, std::vector<OpenImageIO_v2_4_5::ParamValue, std::allocator<OpenImageIO_v2_4_5::ParamValue> > >, OpenImageIO_v2_4_5::ParamValue*)':
C:/msys64/ucrt64/include/c++/12.2.0/bits/stl_uninitialized.h:119: undefined reference to `__imp__ZN18OpenImageIO_v2_4_510ParamValue12init_noclearENS_7ustringENS_8TypeDescEiNS0_6InterpEPKvNS0_4CopyENS0_11FromUstringE'
collect2.exe: error: ld returned 1 exit status
[110/112] Building CXX object CMakeFiles/notcurses-static.dir/src/media/oiio.cpp.obj
ninja: build stopped: subcommand failed.

The presence of pthread_cancel() hinders portability on arm-based platforms. We need to look for less problematic alternatives to pthread_cancel(). Look
https://github.com/termux/termux-packages/issues/8860 https://github.com/termux/termux-packages/pull/11626