Draw to X11 windows using only Cairo

[Manolo]

Development of the Wayland platform involved the construction of a full

FLTK graphics driver based on Cairo. This, in turn, allows to experiment with

a Cairo-only X11 graphics driver where all text and graphics use Cairo

and then get displayed in X11 windows. That's what the attached patch to the

current FLTK source tree does.

Installation :

* cd to top  of FLTK source tree

* patch -p1 < Fl_Display_Cairo_Graphics_DriverV7.patch.txt

* build FLTK with CMake turning these 2 options ON

     ・ OPTION_USE_PANGO

     ・ OPTION_CAIROXLIB        <=== this activates the new stuff

The result is fully antialiased text and graphics.

Using application test/doublebuffer, my first impression is that Cairo graphics

are relatively slow when they are in an Fl_Window but are as fast as standard

X11 graphics when they are in an Fl_Double_Window.

[imm]

Thanks Manolo - this sounds brilliant.
Not actually tried this yet, but I will.
Bill will be pleased too, I'd guess - he's been quite keen on the idea
of a Cairo back-end in the past!

If single-window is problematic, should we consider (for the Cairo
builds) something like macOS has, where a single window is really a
double window anyway?
Though... that might be tricky to actually implement, given that
double currently derives from single, I think...

[Bill Spitzak]

I would go for the "all windows are double buffered" solution if it is indeed faster. This is pretty much what Wayland is doing.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/CAGFM6daKbWZX6bSWpYGMHhR%3DHru0Hn1ebYJq%3DYbHxHOkdpdzjw%40mail.gmail.com.

[wcout]

Am 09.03.22 um 16:21 schrieb Manolo:

> Development of the Wayland platform involved the construction of a full
> FLTK graphics driver based on Cairo. This, in turn, allows to experiment
> with
> a Cairo-only X11 graphics driver where all text and graphics use Cairo
> and then get displayed in X11 windows. That's what the attached patch to the
> current FLTK source tree does.

Great achievement!

My simple test measurements with an older notebook under Ubuntu 20.04
show that FLTK's Cairo drawing speed is a fector 10 times slower than
FLTK's X11 drawing. But that must not mean anything. Anyway the actual
performance of the FLTK test programs feels pretty good.

[imacarthur]

On Thursday, 10 March 2022 at 10:51:43 UTC wcout wrote:

Great achievement!

My simple test measurements with an older notebook under Ubuntu 20.04
show that FLTK's Cairo drawing speed is a fector 10 times slower than
FLTK's X11 drawing. But that must not mean anything. Anyway the actual
performance of the FLTK test programs feels pretty good.

Interesting - In your test, were you using a single_window or a double_window for the test app window?

Or (better!) do you have metrics that would allow us to quantify Manolo's observation that the single_window seems to be slower than the double_window case?

FWIW, I haven't found the cycles to try this myself yet, but what (limited) experience I have of Cairo in the past suggests that some operations are often "nearly as fast as native" and others can be surprisingly slow. (And, possibly, that where that difference lies depends on the system used, GPU, others factors I do not know...)

Be good if we can quantify this to some degree, if only as a guide.

[wcout]

> Interesting - In your test, were you using a single_window or a double_window for the test app window?

I used an image surface (so that probably is like single window) because I wanted to measure the pure drawing speed without any caching involved.

Attaching this code (nothing special, only a quick hack).
Output is:

X11:

time ./drawing_speed
iterations: 10000

real 0m1,679s
user 0m0,107s
sys 0m0,079s

Cairo:

time ./drawing_speed
iterations: 10000

real 0m20,688s
user 0m1,233s
sys 0m0,737s

[Albrecht Schlosser]

I used another test, inspired by the observation we talked about earlier that resizing the unittest schemes test felt different on some platforms (Windows GDI vs. GDI+ IIRC).

I modified test/unittests to automate the test and the results are very different. I mean: the opposite of @wcout's test: Cairo is always faster than X11 drawing, compared with the same type of (sub)window. The main window of test/unittests is a double window but the schemes test subwindow defaults to Fl_Window. I changed it in my tests to either Fl_Double_Window or Fl_Window, see attached cairo-x11_test.diff.

The X11 tests are executed with Pango enabled which should be equivalent to the Cairo setup.

–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Subwindow type      double    single    double    single
Drawing type        Cairo     Cairo     X11       X11   
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Scheme none         0.475     0.545     1.779     1.964
Scheme gleam        0.569     0.739     1.747     2.267
Scheme plastic      0.815     0.893     1.964     2.283
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––

The measured time is "user" time as in wcout's test above. The raw test results (program output) are in attached file cairo-x11_test.txt.

According to this test Fl_Double_Window is always slightly faster, no matter which drawing type, and Cairo is always faster than X11 by a factor of about 2.4 to 3.7.

The relative difference of measured speed may in parts be due to the fact that my test always (re)draws the entire window directly whereas @wcout's test draws into an image surface.

OK, I tested @wcout's program as well on my Linux notebook (Intel I7):

X11:

iterations: 10000

real    0m0,688s
user    0m0,093s
sys    0m0,052s


Cairo:

iterations: 10000

real    0m0,664s
user    0m0,063s
sys    0m0,080s


In my environment Cairo is also faster than X11 with @wcout's test program (user time: 2/3).


BTW: IMHO the raw drawing speed is not really relevant in many programs that use a more or less "static" GUI and rely on user interaction (data entry). In such situations big redraws will not happen frequently.

Game-like programs with heavy (re)draws or image viewers and manipulation programs might make a difference but then developers might use other drawing features anyway (OpenGL or a gaming engine).

[imacarthur]

On Thursday, 10 March 2022 at 14:48:43 UTC Albrecht Schlosser wrote:

In my environment Cairo is also faster than X11 with @wcout's test program (user time: 2/3).

Interesting: I suspect this may be related to my observation that Cairo performance seems to vary a fair bit depending on the machine that runs it (I'm guessing here that Albrecht's machine is a more "modern" spec. than wcout's machine, which was described as an "older laptop", which might go some way towards the difference?)

 

BTW: IMHO the raw drawing speed is not really relevant in many programs that use a more or less "static" GUI and rely on user interaction (data entry). In such situations big redraws will not happen frequently.

Game-like programs with heavy (re)draws or image viewers and manipulation programs might make a difference but then developers might use other drawing features anyway (OpenGL or a gaming engine).

This is true; I know that people (including me!) have used fltk to render GUI with a lot of complex and dynamic redraws, which might be affected negatively by something like this, but the general case  for a GUI that changes at "user speed" is unlikely to be affected much, if at all, by this sort of speed difference, and should always look better with Cairo.

[Bill Spitzak]

If Double Window is faster, then the Image also has to be changed to be a local memory buffer to get the same speed savings.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f135edd6-c6ad-4d17-9d83-65450f1ca7a8n%40googlegroups.com.

[imm]

On Wed, 9 Mar 2022 at 15:21, Manolo wrote:
>

> Development of the Wayland platform involved the construction of a full
> FLTK graphics driver based on Cairo. This, in turn, allows to experiment with
> a Cairo-only X11 graphics driver where all text and graphics use Cairo
> and then get displayed in X11 windows. That's what the attached patch to the
> current FLTK source tree does.
>
> Installation :
> * cd to top of FLTK source tree
> * patch -p1 < Fl_Display_Cairo_Graphics_DriverV7.patch.txt
> * build FLTK with CMake turning these 2 options ON
> ・ OPTION_USE_PANGO
> ・ OPTION_CAIROXLIB <=== this activates the new stuff
>
> The result is fully antialiased text and graphics.

As an aside - is there a branch for this anywhere? Or is it just the
patch for now?

Cheers,
--
Ian

[imm]

Hmm, just tried the patch against a clean clone of fltk master
(finally found some spare cycles)

patching file src/drivers/Cairo/Fl_Cairo_Graphics_Driver.cxx
Hunk #1 FAILED at 930.
1 out of 1 hunk FAILED -- saving rejects to file
src/drivers/Cairo/Fl_Cairo_Graphics_Driver.cxx.rej

Might try and fix that up manually, but, just FYI.

[imm]

OK - that seems pretty good, worked well, only a few things look awry,
I'm very impressed.
On this (older Dell XPS13) is does seem a bit sluggish compared to
non-Cairo, but that's subjective (i.e. I have not gathered any actual
metrics yet.)

I'm getting a lot of this in the console though:

XRequest.139: RenderBadPicture (invalid Picture parameter) 0x3600012

Also some rendering weirdness in places - sometimes seems to pick an
"unexpected" font face in places, and the text clipping seems to be a
bit off in places as a result. See snapshot "glew-test-2.png", where
the descenders on the "g" and "p" characters are clipped away - this
is not seen (and a different font is used) in the "stock" XLIB
version. There are other instances of that - the selected font just
seems to be a wee bit too big; but in other places the face chosen is
fine.

Also some rendering oddities, e.g. see overl-draw.png. Guess which of
these is stock and which is Cairo...

[wcout]

Am 10.03.22 um 13:18 schrieb wcout:

Interesting observation: I tried this test with an Wayland-enabled compilation of the current FLTK code on the same machine (under an 'Ubuntu with Wayland' session) and the drawing speed is much better:

time ./drawing_speed

iterations: 10000

real 0m2,562s
user 0m2,550s
sys 0m0,008s


The original test was with the Cairo-Patch version of the current FLTK running X11 on a Metacity session.

So something in the Wayland implementation/setting makes Cairo drawing much faster (Wayland caching something?)

Sidenote: The Cairo-Patch version also is a little bit faster under the Wayland-session:
time ./drawing_speed

iterations: 10000

real 0m17,433s
user 0m1,420s
sys 0m1,134s

[Mo_Al_]

I've also noticed faster Cairo drawing (with the patch) than Xlib drawing. Measured the timing of drawing 100,000 buttons with various box types in an Fl_Scroll. Didn't measure scroll speed, but didn't notice delays with Cairo either. 
Tested on a hp laptop running i7-8550U CPU @ 1.80GHz, 16gb ram, 4 cores, nothing too beefy. This was run on WSL2 running VcXsrv X server.

[Manolo]

For easier testing, I've put this code variant in a new branch called display-cairo

of my FLTK fork at https://github.com/ManoloFLTK/fltk

Build with CMake and OPTION_CAIROXLIB and OPTION_USE_PANGO turned on.

[wcout]

Am 15.03.22 um 09:28 schrieb Manolo:

> For easier testing, I've put this code variant in a new branch called display-cairo
> of my FLTK fork at https://github.com/ManoloFLTK/fltk
>

Observing some rare and completely random crashes just clicking around with the demo program.
Luckily I could finally catch one under a debugging session. Seems to have something to do with tooltips:

demo: ../../../../src/cairo.c:524: cairo_destroy: Assertion `CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&cr->ref_count)' failed.

Program received signal SIGABRT, Aborted.

#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff7522859 in __GI_abort () at abort.c:79
#2 0x00007ffff7522729 in __assert_fail_base
(fmt=0x7ffff76b8588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7ffff7c7a700 "CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&cr->ref_count)", file=0x7ffff7c7a697 "../../../../src/cairo.c", line=524, function=<optimized out>) at assert.c:92
#3 0x00007ffff7534006 in __GI___assert_fail
(assertion=0x7ffff7c7a700 "CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&cr->ref_count)", file=0x7ffff7c7a697 "../../../../src/cairo.c", line=524, function=0x7ffff7c7a758 "cairo_destroy") at assert.c:101
#4 0x00007ffff7c14fe9 in () at /usr/lib/x86_64-linux-gnu/libcairo.so.2
#5 0x00005555555bc263 in Fl_X11_Window_Driver::hide() (this=0x555555805e30)
at drivers/X11/Fl_X11_Window_Driver.cxx:434
#6 0x00005555555a3e84 in Fl_Window::hide() (this=0x55555580bdf0) at Fl_Window.cxx:555
#7 0x00005555555a12b0 in Fl_Tooltip::exit_(Fl_Widget*) (w=0x0) at Fl_Tooltip.cxx:251
#8 0x00005555555a1107 in Fl_Tooltip::enter_(Fl_Widget*) (w=0x55555572cf20) at Fl_Tooltip.cxx:207
#9 0x0000555555572f71 in Fl::handle_(int, Fl_Window*) (e=11, window=0x5555556745e0) at Fl.cxx:1244
#10 0x0000555555572cab in Fl::handle(int, Fl_Window*) (e=11, window=0x5555556745e0) at Fl.cxx:1157
#11 0x00005555555c2730 in fl_handle(_XEvent const&) (thisevent=...) at Fl_x.cxx:2064
#12 0x00005555555bcfa8 in do_queued_events() () at Fl_x.cxx:116
#13 0x00005555555bd32f in fd_callback(int, void*) () at Fl_x.cxx:312
#14 0x00005555555e5f87 in Fl_Unix_System_Driver::poll_or_select_with_delay(double) (this=
0x55555565e250, time_to_wait=11.970500999999993) at drivers/Unix/Fl_Unix_System_Driver.cxx:814
#15 0x00005555555bd047 in Fl_X11_System_Driver::poll_or_select_with_delay(double)
(this=0x55555565e250, time_to_wait=11.970500999999993) at Fl_x.cxx:138
#16 0x00005555555e638e in Fl_Unix_System_Driver::wait(double)
(this=0x55555565e250, time_to_wait=11.970500999999993)
at drivers/Unix/Fl_Unix_System_Driver.cxx:855
#17 0x0000555555571d99 in Fl::wait(double) (time_to_wait=1e+20) at Fl.cxx:482
#18 0x0000555555571dc1 in Fl::run() () at Fl.cxx:502
#19 0x0000555555571482 in main(int, char**) (argc=1, argv=0x7fffffffdf38) at demo.cxx:613


Just tried again with this assumption and now I can replicate:

Start any program using tooltips and wait for a tooltip to appear. At the second time the crash occurs.

[Manolo]

Le samedi 23 avril 2022 à 04:59:44 UTC+2, wcout a écrit :

Am 15.03.22 um 09:28 schrieb Manolo:
> For easier testing, I've put this code variant in a new branch called display-cairo
> of my FLTK fork at https://github.com/ManoloFLTK/fltk
>

Observing some rare and completely random crashes just clicking around with the demo program.
Luckily I could finally catch one under a debugging session. Seems to have something to do with tooltips:

………

Just tried again with this assumption and now I can replicate:

Start any program using tooltips and wait for a tooltip to appear. At the second time the crash occurs.

Good catch. There was indeed a logical error in the cairo-related code.
That should be fixed now in the git repo (both FLTK master and ManoloFLTK display-cairo branch).