FLTK logo

Article #622: New Poll: FLTK2 and Cairo

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Articles | Show Comments | Submit Comment ]

Article #622: New Poll: FLTK2 and Cairo

Created at 11:09 Jun 27, 2006 by matt

Last modified at 11:28 Jun 27, 2006

What is Cairo

Cairo is a cross-plarform render engine, creating graphics and text in excellent quality. See also: wikipedia, cairo home, Win32 Screenshot vs. Cairo Screenshot, another Cairo Screenshot

How does Cairo benefit FLTK2?

Cairo would replace all system-dependent calls to 2D graphics rendering in FLTK2, making it easier to maintain the code base and generating much nicer graphics, opening up a wealth of new features to all FLTK2 developers. Cairo renders into image buffers, renders text along spline curves, can render backgrounds, highlights, grades, etc. . It is LGPL like FLTK2 and runs on all our supported platforms.

So let me list the positives:


      
  • beautiful, beautiful, beautiful
      
  • easier to maintain for about 30% of the system dependent code
      
  • many new graphics features (alpha blending, rotated text, ...)
      
  • perfect offscreen buffer rendering, printing(?)

What are the drawbacks?

There are drawbacks of course.


      
  • FLTK2 would become dependent on an external library
      
  • Cairo is fast, but native code is much faster
      
  • Cairo adds considerable size to FLTK2
      
  • Themse must be developed that actually use the power of Cairo

What's a developer to do?

Please make sure to voice your opinion using our Poll #20

Matthias

Listing ]


Comments

Submit Comment ]

From zaplia.mail, 07:22 Jul 12, 2006 (score=3)

AGG is better in some parts then Cairo: 1. Well ported to Win32 2. Allow fast low level operations with buffers and curves 3. The whole library looks cleaner then Cairo ( subjectiv ) But Cairo is in broad use and development, modern mainstream... There is positiv experience of dynamic SVG rendering with AGG+FLTK1.6 for Win32 and X11-desktop. Speed is not top-fast but is usefull already, and could be increased if apropriate layering of buffers is used. Antialiasing is very good for complex curves. Simple, it was faster to implement such thing with AGG then with Cairo (subjectiv).
Reply ]

From Anonymous, 02:19 Jul 03, 2006 (score=3)

Most of us think about such an abstract/decoupled layer, but for now, we will first finalize our cairo impl. as it is in itself quite some work already. This said, such an abstraction should be the next step ;-)
Reply ]

From fabien, 03:15 Jun 28, 2006 (score=3)

IMHO I think it would give users a better idea of the cairo rendering to watch the following snapshot of arc demo with alpha blending:
  http://fab672000.free.fr/fltk/arc_demo2.png
Reply ]

From rtrocca, 02:48 Jun 28, 2006 (score=3)

I think that Cairo can be a good idea. Personally, however, I prefer AGG, even if AGG is much lower lever than Cairo. Furthermore AGG is very hard to grasp. I still did not have a look at FLTK2, but I'd say that the better solution would be to have some kind of fl_device, that you can decide at compile time. For example this would lead to these advantages:

  • developer can create a new fl_device and propose it to community it he whishes
  • on Linux we can use Cairo or whatever else;
  • on Windows, well, possibilities are countless (I'm a win dev):
    • fl_device_gdiplus
    • fl_device_gdi
    • fl_device_directx
In this way it would be possible to have the best back-end for the task. I can imagine people that has to deploy apps for old win32 systems and they need it to be light without many dependencies, or others who prefer the smooth rendering of GDI+, while people who cares about the maximum quality possible, would deploy an app that will use AGG.

In my (not much) spare time, I'm experimenting with making an fl_device class for fltk1 that uses GDI+, just for fun :-)

So, please do not stick with 1 API for everybody but give choice to the user.


Reply ]

From matt, 03:33 Jun 28, 2006 (score=3)

I wholeheartedly agree. I would even go so far to make the fl_device mostly a runtime decision. That way, we could render arbitray FLTK widgets right into OpenGL windows (or DirectX) simply by changing the fl_device.

PS: I only set up the poll. The original implementation comes from Bill. Fabien is currently greatly expanding it.
Reply ]

From flmn, 19:54 Jun 27, 2006 (score=1)

why not Anti-Grain Geometry (AGG) ? http://www.antigrain.com/

the performance of Cairo on win32 is awful.
Reply ]

From fabien, 04:35 Jun 28, 2006 (score=3)

This may not be really true. One should not be fooled with the fast window resize they seems to have on their demos. A precise example of this is the rasterizers.exe demo with only two triangles and alpha blending. If you resize the window it seems fast but just does not resize anything because no recalculation is made on resize(the drawing is just moved and clipped). Then when you check the performance option, this is confirmed by the fact that an antialiased redraw takes (on my fast desktop machine) half a second to redraw according to the result dialog box ...
Reply ]

 
 

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