| [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3284
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 4 - High, e.g. key functionality not working |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Cairo |
Summary: | Cairo integration needs redesign |
Version: | 1.4-feature |
Created By: | AlbrechtS |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | several (unknown) |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#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. https://groups.google.com/d/msg/fltkgeneral/_C1OJhMLQl0/pHUFtz9SCwAJ
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: https://groups.google.com/forum/#!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. | |
|
#6 | AlbrechtS 09:43 Jun 02, 2021 |
| I think the screen scaling issue has already been fixed. | |
|
#7 | AlbrechtS 13:52 Nov 26, 2022 |
| Fixed in Git repository.
All the main issues have meanwhile been fixed in git 'master' and will be in the upcoming release 1.4.0. Details:
- FLTK_HAVE_CAIRO is now defined in the new fl_config.h which is always included in user code
- Fluid can be instructed to delay inclusion of FL/Fl.H but this is no longer necessary (see above)
- full Cairo rendering has been implemented in FLTK 1.4 (Linux, Wayland, X11)
- I withdraw the idea to create a new Fl_Cairo class
- FLTK programs depend on Cairo if and only if FLTK has been configured with --enable-cairoext. This can't be avoided.
- Cairo scaling has been fixed.
Closing this issue (w/Resolution). | |
[ Return to Bugs & Features ]
|
| |