STR #3284

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #3284

Application:FLTK Library
Status:5 - New
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Summary:Cairo integration needs redesign
Created By:AlbrechtS
Assigned To:AlbrechtS
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 AlbrechtS
11:30 Feb 13, 2016
FLTK 1.3 has Cairo integration with Fl_Cairo_Window, however this needs the correct definitions in FL/Fl.H - basically you can say that FL/Fl.H depends on #include <config.h> because it references preprocessor macros defined in config.h. After a recent fix in svn r11167 (branch-1.3) and r11168 (branch-1.3-porting) this was reduced to a dependency on FLTK_HAVE_CAIRO which must be defined *before* including FL/Fl.H.

Such a #define should never be needed in user code.

Even worse: fluid writes "#include FL/Fl.H" as the very first statement (except an optional comment) into generated header files. This prevents using fluid with Fl_Cairo_Window.

This has been discussed in fltk.general, which led to the commits mentioned above, but this is not a complete solution.

The only known workaround in FLTK 1.3 is to #define FLTK_HAVE_CAIRO on the command line when compiling fluid-generated code or to add this as CXXFLAGS when configuring the build so this is listed by fltk-config:

CXXFLAGS="-DFLTK_HAVE_CAIRO" ./configure --enable-cairo
./fltk-config --cxxflags

or to define this in the CMake options.

Conclusion: CMake support with FLTK 1.4 should be redesigned. FL/Fl.H must not depend on configuration dependent preprocessor macros. It should be possible to use Fl_Cairo_Window's by just including:

#include <FL/Fl_Cairo_Window.H>
#2 AlbrechtS
11:33 Feb 13, 2016
Correction: The last paragraph should read:

Conclusion: Cairo support with FLTK 1.4 should be redesigned. FL/Fl.H must not depend on configuration dependent preprocessor macros. It should be possible to use Fl_Cairo_Window's by just including:

#include <FL/Fl_Cairo_Window.H>
#3 AlbrechtS
11:55 Feb 13, 2016
Unless we implement full Cairo rendering in FLTK 1.4 ... ;-)

... one possible solution would be to remove all Cairo related stuff (mainly static methods) from FL/Fl.H, i.e. from class Fl. These methods could be moved to class Fl_Cairo, so that Fl.H would not need any dependencies on Cairo stuff.

I'm aware that this would break the API (i.e. user code that uses the Cairo related static methods declared in Fl.H), but these methods should be used less frequently and probably only in a few places in user code.

User and FLTK code that uses:

 - Fl::cairo_autolink_context()
 - Fl::cairo_cc()
 - Fl::cairo_make_current()         (private anyway)
 - Fl::Fl_Cairo_State cairo_state_  (private anyway)

would have to be changed to use

 - Fl_Cairo::autolink_context()
 - Fl_Cairo::cc()
 - Fl_Cairo::make_current()         (private anyway)
 - Fl_Cairo::State cairo_state_     (private anyway)

... or similar methods (maybe other names).

Usage of Fl_Cairo_Window itself would not be changed at all AFAICT now.

Besides that we could keep these methods for backward compatibility in class Fl, but then they would need to return for instance 'void *' instead of 'cairo_t *' etc. which could also break user code (in some cases casts would be needed).

Note: We had small API changes from 1.1 to 1.3 and even larger API changes from 1.0 to 1.1 (documented in the resp. "porting" chapter). Hence I believe that we could look further into this proposal - or find a better one.

Plan B would be to use full Cairo rendering, but we'd still need to support Fl_Cairo_Window for backwards compatibility.

All comments appreciated.
#4 AlbrechtS
16:00 Nov 26, 2016
Manfred Herr reported in fltk.general that even applications that don't use cairo get a linker error (undefined reference: Fl::cairo_make_current) if FLTK was configured with --enable-cairoext.

Please see this thread in fltk.general:!topic/fltkgeneral/x80qQ6wt0s4

After testing I could verify this, and it is obvious that --enable-cairoext makes FLTK call Fl::cairo_make_current() internally which produces a dependeny on libfltk_cairo and indirectly on libcairo and libpixman-1, hence all programs must be linked with these additional libraries.

Some thoughts (just thoughts, need more investigation):

This should at least be clarified in the documentation or, if possible, be avoided. I can imagine a function like fl_register_images() -- maybe fl_register_cairo() ? -- that would need to be called to enable Cairo support. Programs that use Cairo would have to call this to enable the full Cairo integration. Only these programs would also depend on libfltk_cairo, libcairo, and libpixman-1. Internally this function could resolve some (libfltk_)cairo functions by loading these functions dynamically, or something similar...
#5 AlbrechtS
08:56 Feb 07, 2020
Note to myself: internal Cairo support needs to take care of builtin screen scaling. Hopefully we can set an appropriate scaling factor to synchronize FLTK screen scaling and Cairo scaling.  
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.