noisy fltk-config

[Evan Laforge]

Hi, this is a minor issue but pretty visible. In latest fltk from
github, every run of fltk-config prints "grep:
/nix/store/c20mk84ykvyfzixcxr0yg41sbrxsrfx4-fltk-1.4-c0f5080cb056919e898ac572e72fd62568dc307a/bin/FL/fl_config.h:
No such file or directory" which is quite frequent if build files are
using it.

I tracked this down to 6546814a23, which inserts a `if grep -q
'^#define FLTK_HAVE_CAIRO 1' $selfdir/FL/fl_config.h` in
fltk-config.in. Unfortunately this only works if fltk-config is in
the original source directory, and not if it's in an installed
location (nix weirdness above, but /usr/local/bin would have the same
problem I think). I'm not really sure what the fix is, hence sending
this note rather than a PR! But presumably it should know if cairo is
configured via @ substitution thing autotools does, rather than trying
to find a header, or at least it could know the absolute path to the
installed header presumably also via magic @s.

Coincidentally, I'm interested in trying out the cairo backend so I'm
glad to see an example in there :)

[Greg Ercolano]

On 1/23/22 01:12, Evan Laforge wrote:

Hi, this is a minor issue but pretty visible.  In latest fltk from
github, every run of fltk-config prints "grep:
/nix/store/c20mk84ykvyfzixcxr0yg41sbrxsrfx4-fltk-1.4-c0f5080cb056919e898ac572e72fd62568dc307a/bin/FL/fl_config.h:
No such file or directory" which is quite frequent if build files are using it.
I tracked this down to 6546814a23,

    Oh, yeah that's mine.. was to get the new cairo example in examples/cairo-draw-x.cxx
    to build, as we don't currently have a way to detect cairo any other way. (the old
    technique was flawed too, which checked for the presence of the .lib)

    Just pushed b275ff071 which should solve that -- can you try that and follow up?

    Yes, the right solution is to tweak 'configure' to set a variable and have that be
    expanded into fltk-config.

    I'm afraid I don't know 'configure' at all, so I'm not the one that could implement
    that change -- I think Albrecht mentioned it was something he was going to adapt.

[Albrecht Schlosser]

On 1/23/22 10:12 Evan Laforge wrote:
> Hi, this is a minor issue but pretty visible. In latest fltk from
> github, every run of fltk-config prints "grep:
> /nix/store/c20mk84ykvyfzixcxr0yg41sbrxsrfx4-fltk-1.4-c0f5080cb056919e898ac572e72fd62568dc307a/bin/FL/fl_config.h:
> No such file or directory" which is quite frequent if build files are
> using it.
>

> I tracked this down to 6546814a23, which inserts a `if grep -q...`
[...]
> ... presumably it should know if cairo is

> configured via @ substitution thing autotools does, rather than trying
> to find a header, or at least it could know the absolute path to the
> installed header presumably also via magic @s.

Yep, that's the plan. I'm going to change this once I figured out
another Cairo build related issue.

Greg's commit was only a temporary fix as he wrote too in another reply
and he "fixed the fix" in another commit.

> Coincidentally, I'm interested in trying out the cairo backend so I'm
> glad to see an example in there :)

The current Cairo support is not really a "backend", i.e. it doesn't
turn FLTK into drawing with Cairo.

It only enables users to draw into an Fl_Cairo_Window in a callback
rather than deriving a subclass or setting up drawing with Cairo
manually (which should be possible with the stock FLTK library w/o its
limited Cairo support as well. If that's what you want to do, that
example is applicable.

[Ian MacArthur]

On 23 Jan 2022, at 13:21, Albrecht Schlosser wrote:
>
>> Coincidentally, I'm interested in trying out the cairo backend so I'm
>> glad to see an example in there :)
>
> The current Cairo support is not really a "backend", i.e. it doesn't turn FLTK into drawing with Cairo.
>
> It only enables users to draw into an Fl_Cairo_Window in a callback rather than deriving a subclass or setting up drawing with Cairo manually (which should be possible with the stock FLTK library w/o its limited Cairo support as well.

This is what I do (use “stock” fltk, without the Cairo back-end, to draw with Cairo “manually” into my window) when I want to use Cairo.
Though, as many here will know, I find Cairo is often painfully slow on a lot of platforms... So it’s not a thing I use a lot, TBH.

> If that's what you want to do, that example is applicable.

I think Manolo’s Wayland work may make it possible, at some point, to use that Cairo back-end to render fltk with X11 or Wayland, so it might be worth poking at his branch to see if that could be made to work for you (if you need a “full-Cairo” fltk implementation, I mean...)

[Albrecht Schlosser]

On 1/23/22 17:31 Ian MacArthur wrote:

On 23 Jan 2022, at 13:21, Albrecht Schlosser wrote:

The current Cairo support is not really a "backend", i.e. it doesn't turn FLTK into drawing with Cairo.

It only enables users to draw into an Fl_Cairo_Window in a callback rather than deriving a subclass or setting up drawing with Cairo manually (which should be possible with the stock FLTK library w/o its limited Cairo support as well.

This is what I do (use “stock” fltk, without the Cairo back-end, to draw with Cairo “manually” into my window) when I want to use Cairo.

Ian, I'd be interested in your "manual" way to setup for Cairo drawing in stock fltk for two reasons:

(1) curiosity and maybe using it for simple drawings

(2) as another example for drawing with Cairo in FLTK.


The latter is more important. I'd like to document this if it can be done easy enough with a little platform dependent code on all three major platforms supported by FLTK. If we could do this users would be able to use Cairo drawings w/o Fl_Cairo_Window (as you do) *and w/o having to use --enable-cairo*, maybe for their own widgets, labels, or whatever.

Although we need to keep the current "Cairo support" for backwards compatibility I'd really like to point out working alternatives to users.

I'd appreciate if you could post a "simple example" we can use to document this feature (maybe a similar "draw an X" example as Greg's). I could probably try to find this out myself but if you have working code ... TIA.

[Evan Laforge]

On Sun, Jan 23, 2022 at 8:31 AM Ian MacArthur wrote:
> This is what I do (use “stock” fltk, without the Cairo back-end, to draw with Cairo “manually” into my window) when I want to use Cairo.
> Though, as many here will know, I find Cairo is often painfully slow on a lot of platforms... So it’s not a thing I use a lot, TBH.

I'm interested in cairo because I have scrolling and zooming thing in
pure fltk, that tried to do incremental redraw on scrolling, but was
slow (for some reason I forget now, but presumably due to the overhead
to figure out what to draw, which is then called on every pixel) and
buggy (incremental is complicated and hard to get right). Then I
turned off incremental redraw to draw everything, and it was slow when
zoomed out (lots of stuff to draw!). So I switched to caching the
whole thing in an image, which reversed it to be fast when zoomed out,
but slow when zoomed in (large image!). So I've been thinking of
tiling, or maybe just switching methods at some zoom level, but was
looking at what Ardour does... and it seems to be a cairo backed
canvas that as far as I can tell always redraws from scratch on a
scroll. And it sure seems to be fast enough! And it gets
transparency and gradients and anti-aliasing on linux! How do they do
that!?

I guess I should just try it and see.

[Ian MacArthur]

On 23 Jan 2022, at 17:27, Albrecht Schlosser wrote:
>
> On 1/23/22 17:31 Ian MacArthur wrote:
>> On 23 Jan 2022, at 13:21, Albrecht Schlosser wrote:
>>
>>> The current Cairo support is not really a "backend", i.e. it doesn't turn FLTK into drawing with Cairo.
>>>
>>> It only enables users to draw into an Fl_Cairo_Window in a callback rather than deriving a subclass or setting up drawing with Cairo manually (which should be possible with the stock FLTK library w/o its limited Cairo support as well.
>>>
>> This is what I do (use “stock” fltk, without the Cairo back-end, to draw with Cairo “manually” into my window) when I want to use Cairo.
>
> Ian, I'd be interested in your "manual" way to setup for Cairo drawing in stock fltk for two reasons:
>
> (1) curiosity and maybe using it for simple drawings
>
> (2) as another example for drawing with Cairo in FLTK.

I’ve attached an old example below.
TBH, it wasn’t the example I was looking for, but this seems to be what I have on this Mac... The other “simple” example must be on another machine... somewhere...

That all said, I think I have posted this before, and have a vague recollection of others complaining it didn’t work for them, or that the origins are weird or some such (I forget what was wrong) but it works OK for me, on this Mac, and on Win10 and some debian box...

[Albrecht Schlosser]

On 1/23/22 21:44 Ian MacArthur wrote:

On 23 Jan 2022, at 17:27, Albrecht Schlosser wrote:

Ian, I'd be interested in your "manual" way to setup for Cairo drawing in stock fltk for two reasons:

(1) curiosity and maybe using it for simple drawings

(2) as another example for drawing with Cairo in FLTK.

I’ve attached an old example below.
TBH, it wasn’t the example I was looking for, but this seems to be what I have on this Mac... The other “simple” example must be on another machine... somewhere...

Thanks, I could build and run it on Linux.

That all said, I think I have posted this before, 

Yep, I remember that I've seen this example already.

and have a vague recollection of others complaining it didn’t work for them, or that the origins are weird or some such (I forget what was wrong) but it works OK for me, on this Mac, and on Win10 and some debian box...

I found out that it doesn't scale correctly with ctrl/+/-/0 but I also found a quick fix for my Linux box. I didn't bother to fix the macOS or Windows versions yet but I'll look into this later. Thank you very much for this small demo.

I'm attaching my modified version. The fix is maybe not optimal but it sets the correct scaling factor on X11. It was as simple as finding the correct scaling factor and multiplying it to the surface size and then using cairo_scale() to apply it to the drawing.

int sn = window()->screen_num();

float scale = Fl::screen_scale(sn); // get scaling factor of screen sn

...

/* Get a Cairo surface for the box, based on the enclosing window */ /* ... use scaling factor ... */

surface = cairo_xlib_surface_create(fl_display, fl_window, fl_visual->visual, pt->w()*scale, pt->h()*scale); ...

/* Store the cairo context */

cairo_context = cairo_create(surface);

cairo_scale(cairo_context, scale, scale); /* apply cairo scaling */

That's all I remember but an interested reader can compare your version and mine.

I'll test and modify this for Windows and macOS later, maybe tomorrow.

[Greg Ercolano]

On 1/23/22 12:10, Evan Laforge wrote:

I'm interested in cairo because I have scrolling and zooming thing in
pure fltk, that tried to do incremental redraw on scrolling, but was slow[..]

    Evan: can you verify the fix commit I pushed last night solved your issue?
    My request for follow up may have been buried by the OT thread, e.g.:

I tracked this down to 6546814a23,

    Oh, yeah that's mine.. that was to get the new cairo example in examples/cairo-draw-x.cxx

[Evan Laforge]

> Evan: can you verify the fix commit I pushed last night solved your issue?
> My request for follow up may have been buried by the OT thread, e.g.:

Ah yes, indeed it's quiet now. I don't have cairo enabled but I
eyeballed the script and it looks like it would have detected it if I
did.