Slow response when calling Fl_Text_Editor::buffer()

[Eric Sokolowsky]

I have been experiencing slow performance when using Fl_Text_Editor in my application. I see a significant delay (some 7 seconds) when calling Fl_Text_Editor::buffer on a new Fl_Text_Buffer when my application starts. Is this normal behavior? I'm just so used to FLTK working almost instantly for every operation that this was surprising to me. I'm using FLTK 1.3.4 because I cannot right now move to a newer version of FLTK, because of system dependencies. Here's a snippet of the code I use, together with some debugging output so I could tell why it was being slow:

int w = 800;  // width of window
int h = 25;   // height of one widget
int m = 10;    // blank margin
int sw = 80;   // standard width

Fl_Double_Window *main_window = new Fl_Double_Window(w, 615, hw::progname().c_str());
ypos += h + 5;

Fl_Text_Editor *caption_text = new Fl_Text_Editor(xpos, ypos, w - xpos - m, 5*h, "Caption Text: ");
std::cout << "Checkpoint 5.2.1: " << timer.elapsed() << "\n";
caption_text->align(FL_ALIGN_LEFT);
std::cout << "Checkpoint 5.2.2: " << timer.elapsed() << "\n";
caption_text->callback((Fl_Callback*) cb_caption_text, &show);
std::cout << "Checkpoint 5.2.3: " << timer.elapsed() << "\n";
caption_text->when(FL_WHEN_CHANGED);
std::cout << "Checkpoint 5.2.4: " << timer.elapsed() << "\n";
Fl_Text_Buffer *caption_buf = new Fl_Text_Buffer;
std::cout << "Checkpoint 5.2.5: " << timer.elapsed() << "\n";
caption_text->buffer(caption_buf);
std::cout << "Checkpoint 5.2.6: " << timer.elapsed() << "\n";
caption_text->wrap_mode(Fl_Text_Editor::WRAP_AT_BOUNDS, 5);
std::cout << "Checkpoint 5.2.7: " << timer.elapsed() << "\n";

Here's some of the output:

Checkpoint 1: 0.0038885
Checkpoint 2: 0.00390178
Checkpoint 3: 0.00391342
Checkpoint 4: 0.00393642
Checkpoint 5: 0.00394311
Checkpoint 5.1: 0.00394802
Checkpoint 5.2: 0.00395305
Checkpoint 5.2.1: 0.00396602
Checkpoint 5.2.2: 0.00397152
Checkpoint 5.2.3: 0.0039758
Checkpoint 5.2.4: 0.00398055
Checkpoint 5.2.5: 0.00399762
Checkpoint 5.2.6: 6.98275
Checkpoint 5.2.7: 6.98277
Checkpoint 5.3: 6.98278
Checkpoint 6: 6.98278
Checkpoint 7: 6.9828

As you can see, the delay comes from the line where the editor is given the text buffer to use. Everything else is fast, as expected.

Any light that could be shed on this would be appreciated.

Eric

[Gonzalo Garramuño]

On 19/4/24 10:43, Eric Sokolowsky wrote:
>
> As you can see, the delay comes from the line where the editor is
> given the text buffer to use. Everything else is fast, as expected.
>
> Any light that could be shed on this would be appreciated.

Just a guess here.  But WRAP_AT_BOUNDS forces your editor to re-align
the text (add line-feeds) and you are using 5 columns, so if your text
lines are long your text is wrapped very often.  Try WRAP_NONE and see
if it improves the response.  If it does, you found the culprit.

--
Gonzalo Garramuño
ggar...@gmail.com

[Eric Sokolowsky]

Thank you for your response.

I don't think that this is the problem, because the slow call happens before the wrap mode is set, in the call to buffer(). Besides, no text has been given to the buffer yet anyway.

Eric

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/7bba338c-1a96-4afe-a81e-a0ad0bc8cee5%40gmail.com.

[Albrecht Schlosser]

On 4/19/24 15:43 Eric Sokolowsky wrote:

I have been experiencing slow performance when using Fl_Text_Editor in my application. I see a significant delay (some 7 seconds) when calling Fl_Text_Editor::buffer on a new Fl_Text_Buffer when my application starts. Is this normal behavior? I'm just so used to FLTK working almost instantly for every operation that this was surprising to me. I'm using FLTK 1.3.4 because I cannot right now move to a newer version of FLTK, because of system dependencies. Here's a snippet of the code I use, together with some debugging output so I could tell why it was being slow:

[...]

As you can see, the delay comes from the line where the editor is given the text buffer to use. Everything else is fast, as expected.

Any light that could be shed on this would be appreciated.

Eric, the FLTK version (1.3.4) you are using is more than 7 years old which means that the issue you are reporting would very likely have been fixed long ago. It's very surprising that the buffer assignment alone would cause a delay of almost 7 seconds.

I would have suggested you to create a small, complete (i.e. compileable) example program that shows the issue, and that you test this program with a newer FLTK version, either 1.3.9 or 1.4.0 (git).

But then I decided to copy and modify your code snippet and to try it myself. I removed only one statement and all the timer lines.

Result: I can't confirm the issue, neither with 1.3.4, 1.3.9 nor 1.4.0.

Here's my demo program with test results using 1.3.4 (built for this test!) and 1.4.0:
```

$ cat test/hello.cxx
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Text_Editor.H>
#include <stdio.h>

int w = 800;
Fl_Double_Window *window = nullptr;

void close_cb(void *p) {
  window->hide();
}

int main(int argc, char **argv) {
  window = new Fl_Double_Window(w, 615, "TEST");
  Fl_Text_Editor *caption_text = new Fl_Text_Editor(10, 10, w - 20, 125, "Caption Text: ");
  caption_text->align(FL_ALIGN_LEFT);
  caption_text->when(FL_WHEN_CHANGED);
  Fl_Text_Buffer *caption_buf = new Fl_Text_Buffer();
  caption_text->buffer(caption_buf);
  caption_text->wrap_mode(Fl_Text_Editor::WRAP_AT_BOUNDS, 5);
  window->end();
  window->show(argc, argv);
  printf("\nFL_API_VERSION = %d\n", FL_API_VERSION);
  Fl::add_timeout(0.001, close_cb, nullptr);
  return Fl::run();
}

$ fltk-config --compile test/hello.cxx && time ./hello
/usr/bin/c++ -I/usr/local/fltk/1.4-debug/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o hello test/hello.cxx /usr/local/fltk/1.4-debug/lib/libfltk.a -lm -lpthread -lXinerama -lXfixes -lXcursor -L/usr/lib/x86_64-linux-gnu -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo -L/usr/lib/x86_64-linux-gnu -lcairo -lgtk-3 -lgdk-3 -lgio-2.0 -lX11 -lXft -lXrender -lwayland-cursor -lwayland-client -lxkbcommon -ldbus-1 -lfontconfig -ldl

FL_API_VERSION = 10400

real	0m0.190s
user	0m0.153s
sys	0m0.032s

$ /git/fltk/branch-1.3/fltk-config --compile test/hello.cxx && time ./hello
g++ -I/git/fltk/branch-1.3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -o 'hello' 'test/hello.cxx' /git/fltk/branch-1.3/lib/libfltk.a -lXrender -lXcursor -lXfixes -lXext -lXinerama -lpthread -lm -lX11

FL_API_VERSION = 10304

real	0m0.075s
user	0m0.030s
sys	0m0.005s

```

I noticed that 1.4.0 was "significantly slower" (by about 0.12 sec, which is not much), but 1.3.4 was really fast in all my tests. Note that I ran all this on my Debian 10 (Bookworm) Linux system with a recent CPU.

There must be something weird with your system. Please run my test program and report your results. If you still see slow behavior with this test program, please give us more information about your system.

[Eric Sokolowsky]

Thank you for your response.

I tried what you suggested. Here are my timing results on your sample program:

~$ time ./tt

FL_API_VERSION = 10304

real 0m7.955s
user 0m0.030s
sys 0m0.013s

So clearly something is up with my system. Thank you for confirming that this is not expected behavior from FLTK.

Eric

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/61753d9c-d637-493b-adfe-1c04e1547526%40aljus.de.

[Albrecht Schlosser]

On 4/19/24 23:11 Eric Sokolowsky wrote:

Thank you for your response.

Welcome.

I tried what you suggested. Here are my timing results on your sample program:

~$ time ./tt

FL_API_VERSION = 10304

real 0m7.955s
user 0m0.030s
sys 0m0.013s

It's interesting that most of the time is not accounted to the running process (user) nor the system (sys). My first guess would be that the X server or something else is busy and blocks the program, although the assignment of the text buffer should not cause X server communication. See below for more questions.

So clearly something is up with my system.

Yes, looks so. You missed to post info about your system, are you using Unix/Linux (X11) or is it anything else?

Thank you for confirming that this is not expected behavior from FLTK.

Sure, such extraneous "hanging" is not expected. Did you build FLTK yourself, or is it from a system package? Can you rebuild FLTK (even if you're building 1.3.4 again)? If you built FLTK yourself, was it from an official FLTK release tarball, from anywhere else, and does it include any patches? Many questions...

Note: one thing that can cause unpredictable effects is if you mixed FLTK headers from different FLTK versions. Please make sure that you have only one FLTK version (installed or anywhere else) on your system, and make sure that you do a full recompile of FLTK and your application. Note also that FLTK's built-in Makefiles can't guaranteed to rebuild all files if you update source files. CMake is much more reliable with checking build dependencies.

[Eric Sokolowsky]

I'm using Linux (specifically Rocky 8), using the system FLTK. Upgrading to Rocky 9 is in the planning stages, and will bring with it a newer version of FLTK, but I'm not yet ready to upgrade.

I use the application remotely using X11 network protocol to display on my local Macbook Pro. Upon further experimentation, I discovered that if I use a local VNC session instead, it starts much faster. So it does appear that the X11 communication is what is slowing down the app. I am still confused as to why that particular call causes the delay but it's probably not worth worrying about.

I also tried it using FLTK 1.3.9 (both remotely and with VNC) with similar results, which is what I expected.

Thank you again for your help.

Eric

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/75a3137a-b393-499e-b96d-a71c95883259%40aljus.de.

[Manolo]

Le samedi 20 avril 2024 à 13:40:28 UTC+2, eso...@gmail.com a écrit :

I use the application remotely using X11 network protocol to display on my local Macbook Pro. Upon further experimentation, I discovered that if I use a local VNC session instead, it starts much faster. So it does appear that the X11 communication is what is slowing down the app. I am still confused as to why that particular call causes the delay but it's probably not worth worrying about.

I also tried it using FLTK 1.3.9 (both remotely and with VNC) with similar results, which is what I expected.

If you use X11 remotely on your mac, a possibility is that the first time an X11 app runs under XQuartz all fonts

are loaded, and this takes time. If that is the cause of your problems, further X11 app runs should start quick, 

until XQuartz is stopped.

Notice that with version 1.4 of FLTK expected shortly, it will be possible to build FLTK on the mac as an X11

client. This allows in turn to build and run most FLTK client apps on macOS without source code change.