[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
|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|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
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
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:
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:
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_make_current() (private anyway)
- Fl::Fl_Cairo_State cairo_state_ (private anyway)
would have to be changed to use
- 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.
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:
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...
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. ||
[ Return to Bugs & Features | Post Text | Post File ]