Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » UppHub » Cairo
Cairo [message #19705] Tue, 06 January 2009 15:37 Go to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
Hi,

After I read that you are working on a AGG draw control I want to post my unfinished but working cairo control.

It works on Windows and Linux, supports double buffering, easy PDF and SVG output, a Draw compatible drawing class.

To compile the code you have to replace the png.upp file in your uppsrc dir with the one in the zip file.

Included in the zip file are also 2 demo programs.
  • Attachment: cairo.zip
    (Size: 872.42KB, Downloaded 324 times)
Re: Cairo [message #19710 is a reply to message #19705] Tue, 06 January 2009 20:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kodos wrote on Tue, 06 January 2009 09:37

Hi,

After I read that you are working on a AGG draw control I want to post my unfinished but working cairo control.




Well, I am afraid that providing control is the same mistake as has been done in previous attempts.

We do not need control.

What we REALLY need is to draw to ImageBuffer. And provide meaningful way how to store such drawing and how to print it (like DrawingDraw).

This really is multitarget effort - and one important target is to support drawing in non-GUI apps (think webservers).

Once you have rendered raster in ImageBuffer, providing Ctrl is trivial.

Mirek
Re: Cairo [message #19711 is a reply to message #19710] Tue, 06 January 2009 20:45 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
PS.: Thanks anyway, it is a good resource to interface finetuning. (In reality, what I have now is pretty similar).
Re: Cairo [message #19713 is a reply to message #19710] Tue, 06 January 2009 23:23 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
luzr wrote on Tue, 06 January 2009 20:32


What we REALLY need is to draw to ImageBuffer. And provide meaningful way how to store such drawing and how to print it (like DrawingDraw).

This really is multitarget effort - and one important target is to support drawing in non-GUI apps (think webservers).

Once you have rendered raster in ImageBuffer, providing Ctrl is trivial.

Mirek



The Linux control is actually just a wrapper around my cairo class which renders to an image buffer and after that the image buffer is rendered to a control. I think cairo also supports printing, but never tested that one Wink .

This are the 4 methods that are currently implemented to set/create a cairo surface:
void SetSurface(cairo_surface_t *surface, int width, int height);
void SetSurface(ImageBuffer &img);
void CreateSvgSurface(String const &filename, double widthInPoints = 595, double heightInPoints = 841); 
void CreatePdfSurface(String const &filename, double widthInPoints = 595, double heightInPoints = 841);
Re: Cairo [message #19715 is a reply to message #19713] Wed, 07 January 2009 08:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kodos wrote on Tue, 06 January 2009 17:23


The Linux control is actually just a wrapper around my cairo class which renders to an image buffer and after that the image buffer is rendered to a control.



Ops, sorry then Smile

Quote:


I think cairo also supports printing, but never tested that one Wink



Well, the nice thing about that is that cairo or agg printing is irrelevant, as long as we have means to store painting sequence (into Drawing like object) -> we can print Images already, means we can band and render any advanced graphics quite easily too.

BTW, it would be nice to do some benchmark comparisons, now that we have both:)

Mirek
Re: Cairo [message #19716 is a reply to message #19715] Wed, 07 January 2009 09:14 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
luzr wrote on Wed, 07 January 2009 08:14


BTW, it would be nice to do some benchmark comparisons, now that we have both:)



Yes, sure I'll rewrite the benchmarks in cairo if you give me some from AGG Wink

BTW: the CairoDemo in the zip is already a pretty good benchmark Wink
Re: Cairo [message #19718 is a reply to message #19716] Wed, 07 January 2009 11:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
For now, the startpoint is uppdev/SDrawTest Smile

I guess interface are quite similar - it should not be any problem for you. The only problem being, SDraw is not really finished yet Smile

Mirek
Re: Cairo [message #19719 is a reply to message #19718] Wed, 07 January 2009 11:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
CiaroDemo in Win32:

Linking...
Creating library u:\out\MSC9.Debug.Debug_full.Gui\CairoDemo.lib and object u:\out\MSC9.Debug.Debug_full.Gui\CairoDemo.exp
cairolib.obj : error LNK2019: unresolved external symbol _png_set_filler referenced in function _write_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_write_user_transform_fn referenced in function _write_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_packswap referenced in function _write_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_read_user_transform_fn referenced in function _read_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_gray_to_rgb referenced in function _read_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_packing referenced in function _read_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_tRNS_to_alpha referenced in function _read_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_expand_gray_1_2_4_to_8 referenced in function _read_png
cairolib.obj : error LNK2019: unresolved external symbol _png_set_palette_to_rgb referenced in function _read_png
u:\out\MSC9.Debug.Debug_full.Gui\CairoDemo.exe : fatal error LNK1120: 9 unresolved externals

Mirek
Re: Cairo [message #19720 is a reply to message #19719] Wed, 07 January 2009 11:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
(which reminds me that SDraw does not work in Linux now - needs minor text rendering related fix).
Re: Cairo [message #19721 is a reply to message #19705] Wed, 07 January 2009 12:06 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
Hm, did you update your png.upp file? If yes I think you have to manually rebuild the png package because TheIDE doesn't recognize the change.

Quote:


(which reminds me that SDraw does not work in Linux now - needs minor text rendering related fix).



Text rendering is also the problematic part of cairo, currently there is just support for the "toy api" in my implementation. YOu shouldn't really use it in real projects. The best option would be pango, but that would be again another library and the license is probably not that great for U++. LGPL.
Re: Cairo [message #19722 is a reply to message #19721] Wed, 07 January 2009 12:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kodos wrote on Wed, 07 January 2009 06:06


Text rendering is also the problematic part of cairo, currently there is just support for the "toy api" in my implementation. YOu shouldn't really use it in real projects. The best option would be pango, but that would be again another library and the license is probably not that great for U++. LGPL.


In fact, while not everything text-related is implemented yet, it turned out to be surprisingly simple to support current U++ text/font capabilites in SDraw.

Mirek
Re: Cairo [message #19723 is a reply to message #19705] Wed, 07 January 2009 12:44 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
I have to admit that I'm not really into all the text rendering stuff. So I'm not sure how hard it would be to implement the U++ text implementation in cairo.
Re: Cairo [message #19754 is a reply to message #19705] Tue, 13 January 2009 15:38 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
Here is a package with the lion rendering and the Pythagoras tree with SDraw and cairo. Although the SDraw Pythagoras tree doesn't work and I don't know what's wrong. Somehow the rotation isn't applied.
Re: Cairo [message #19755 is a reply to message #19754] Tue, 13 January 2009 17:53 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
The problem is that you cannot apply (at least in current SDraw) the path transformation during path definition. And you had that Rotate after Move (Move starts path, any Fill or Stroke or Clip ends it).

Fixed:

void DoRect(SDraw &sw, double size)
{
	if(size < 0.5)
		return;
	
	sw.Move(0, 0);
	sw.Line(0, size);
	sw.Line(size, size);
	sw.Line(size, 0);
	sw.Fill(Blue());
	
	sw.Begin();
	sw.Translate(0, size);
	sw.Rotate(M_PI/4.);
	DoRect(sw, size / M_SQRT2);
	sw.End();

	sw.Begin();
	sw.Translate(size / 2, 1.5 * size);
	sw.Rotate(-M_PI/4.);
	DoRect(sw, size / M_SQRT2);
	sw.End();
}

void DrawPythagorasTree(Size sz, SDraw *sw, Cairo *ca)
{
	double size = 128;
	
	if (sw)
	{
		sw->Begin();
		sw->Translate(sz.cx / 2 - size / 2, sz.cy);
		sw->Scale(1, -1);
		
		DoRect(*sw, size);
		sw->End();
	}


Mirek
Re: Cairo [message #19756 is a reply to message #19755] Tue, 13 January 2009 17:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, these preliminary results look promising:

TIMING Cairo lion     : 156.00 ms -  7.80 ms (156.00 ms / 20 ), min:  7.00 ms, max:  9.00 ms, nesting: 1 - 20
TIMING Cairo tree     :  2.85 s  - 142.70 ms ( 2.85 s  / 20 ), min: 139.00 ms, max: 146.00 ms, nesting: 1 - 20
TIMING AGGUPP lion    : 46.00 ms -  2.30 ms (46.00 ms / 20 ), min:  1.00 ms, max:  3.00 ms, nesting: 1 - 20
TIMING AGGUPP tree    : 627.00 ms - 31.35 ms (627.00 ms / 20 ), min: 29.00 ms, max: 34.00 ms, nesting: 1 - 20


I have heard AGG is fast. It really is Smile

Mirek

EDIT: I have noticed that in tree, I left AGG to go up to size 0.5, so it was at disadvantage. With the same requirements, it is much faster than that.. (above numbers are updated to size < 1).

[Updated on: Tue, 13 January 2009 17:59]

Report message to a moderator

Re: Cairo [message #19757 is a reply to message #19705] Tue, 13 January 2009 18:04 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
Ah thanks for the fix.

Yes AGG is faster. But I still like cairo better because it supports other surfaces (PDF, PS, SVG, Glitz) and it is actively developed. As I understand the current situation with AGG we are stuck with version 2.4.
Re: Cairo [message #19758 is a reply to message #19757] Tue, 13 January 2009 18:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Well, what we need is rendering engine for ImageBuffer.

SVG, PDF surfaces are relatively simple and planned (PDF as part of current PdfDraw)

BTW, I am trying to model the SDraw interface to be close to SVG requirements - that should make export/import quite simple.

As for active development, it slowly becomes "agg inspired" more and more:) And 2.4 license is perfect for our needs.

BTW, one significant problem with cairo is that (AFAIK) its .so requires X11. Showstopper for web applications.

Mirek
Re: Cairo [message #19759 is a reply to message #19705] Tue, 13 January 2009 20:18 Go to previous messageGo to next message
kodos is currently offline  kodos
Messages: 111
Registered: March 2008
Experienced Member
I think cairo can also be used on a headless server, by just compiling the image surface.

But I have no problem to maintain the cairo package for myself. It suits my needs very well, and is already quite tightly integrated in my current program Wink
I just have to implement some text rendering, probably with the help of the SDraw source Smile
Re: Cairo [message #19760 is a reply to message #19759] Tue, 13 January 2009 22:54 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kodos wrote on Tue, 13 January 2009 14:18

I think cairo can also be used on a headless server, by just compiling the image surface.

But I have no problem to maintain the cairo package for myself. It suits my needs very well, and is already quite tightly integrated in my current program Wink
I just have to implement some text rendering, probably with the help of the SDraw source Smile


Sure. In fact, it should be possible to implement SDraw (well, it will rather be renamed to "Painter") with cairo background quite simply.

Mirek
Previous Topic: DirectoryCreateMulti as an alternative for RealizeDirectory
Next Topic: TabBar. Uninitialized member
Goto Forum:
  


Current Time: Fri Mar 29 15:34:39 CET 2024

Total time taken to generate the page: 0.01401 seconds