AltME groups: search

AGG/Cairo/Skia is the only solution acceptable for me, unless proven 
otherwise.

Certainly no more a nonsense argument than that Enlightenment would 
be unacceptable compared to AGG, Cairo and Skia

One could also just use the drawing library, which then seems to 
be about double the size of Cairo for example, but is much more intelligent

Magnusso - Cyphre said, that he has new framework in mind, kind of 
View like, just a bit abstracted, so that it could use different 
backend systems (Cairo, AGG, Skia, Fog ....). But - not sure his 
target is Red. But maybe we convince him to port it for some fee 
:-)

the lib could be extended step by step with additional backends. 
a good start would be cairo since it's plain ANSI C too.

Well, I don't necessarily like big solutions/libraries. Of course 
it will make sense, if they are already a part of the toolchain, 
e.g. GTK being part of every linux distro, Android, etc. , ditto 
Cairo. So far I could see complaints about AGG not being accelerated, 
and what irritates me about such claims is - we never ever utilised 
full advantage of AGG, yet we complain. And then we are going to 
use crap like Cairo, just becau HW is going to help us. I would rather 
use smaller AGG instead of several times bigger Cairo lib, and orientiate 
myself on HW, which has floating point unit. Before we finish, even 
our small devices are going all to have FPU imo ...

Installing gtk+ dependency: cairo

Downloading http://cairographics.org/releases/cairo-1.12.14.tar.xz
...

I begin to hear the fans in my MacBook.

cairo is a large download

No, it was just his long term idea, to abstract the engine, so that 
it can use various backends - AGG, Cairo, etc, and provide platform 
acceleration, where available. Unfortunatelly, that was just an idea 
on his side, no real project. There is nothing wrong with View engine 
itself, apart from some bugs in core, which make it look unfinished. 
That would not happen with Red, as all sources and hence debugging 
is possible ...

NickA: during my private talks to Cyphre, he told me that if he would 
aproach the View engine nowadays, he would abstract it a bit, so 
that it could use various rendering backends - AGG, Cairo, so that 
where platform permits, it could be HW accelerated. But - such project 
would take some time, and Cyphre would have to be sponsored, in order 
to be able to do the work. I think, that it could be even written 
in a way, so that both R3 and Red benefit. But who knows ...


As for Red - no party is willing to port View engine, yet :-) Doc 
wants to aproach it other way - to use something like VID dialect, 
but final toolkit used would be the native platform one. Kaj did 
some example with Red/System + GTK, if I understand it correctly. 
I still think that even for Red, something like small View  engine 
would be benefical, e.g. for embedded work, where non traditional 
graphics is not a problem.


Dunno, how difficult would it be to get View sources adapted to Red/System. 
Red is missing on timers, events, etc., so maybe later, so that it 
can be naturally plugged in to its architecture ...

he says that it's true that Sugar (their UI) is very slow though. 
he says the reasons are python and cairo.

We should offer them R3 View then :-) "Cairo sucks" is my general 
reaction, even if it might not be true ... just to provoke guys a 
bit :-)

probably python has more bindings (to gtk, cairo, and so on)

PNG can't scale, no? And I can be PNG file smaller than vectors transferred? 
The slowness of whole stuff is another thing.  Dunno if we can support 
SVG out-of-the-box. We are using AGG, while the rest of the world 
is using Cairo.

Later on, guys improved situation a bit - including cool AGG vector 
library into View ... (www.antigrain.com ). This is really cool and 
puts Cairo into trashcan (which is what they should do in the very 
beginning, except the Mozilla politics)

So - everybody going the Cairo way nowadays?

re Cairo: Cairo seems to be popular mainstream. But AGG is used in 
a lot commercial projects silently so it is hard to tell. The facts 
are:  
1. Cairo is slower than AGG.(when comparing SW rendering)

2. Cairo is a graphics library, AGG is a 'kit' to build graphics 
libraries.

Kaj, why AGG nor Cairo were found as insufficient for Syllable purposes? 
IIRC it is Cairo, which will be used by Mozilla platform or even 
OS-X to render, no?

Thats the reason some projects flourish and others die, or lag behind. 
AGG vs Cairo.

Hehe, KDE 4 designer (or Trolltech's dev, dunno), just pissed off 
some Cairo fanboys :-) http://zrusin.blogspot.com/

Cyphre, or others - I am curious. I just read latest blogs about 
Mozilla technology - they will switch rendering to Cairo open source 
library. It will handle svg as well as the rest of rendering too. 
IIRC Cairo was already mentioned here. I wonder how AGG compares?

Cairo seems to be ahead a bit though - buffered imaging, hw usage. 
I do remember that Carl wanted to introduce kind of view plug-ins, 
which should allow faster rendering/blitting?

By the way, our video expert evaluated several drawing libraries, 
among which AGG and Cairo, and deemed them unsuitable for the Syllable 
graphics system

Terry, what you should probably realise is, that that are only probably 
TWO libraries for vector graphics in the open-source world - one 
being AGG, second one being Cairo, library which was selected by 
Mozilla foundation, Apple etc. to do SVG. Both are very good work 
imo ...

One developer was tryting to prepare AGG as an replacement to Mozilla 
Cairo vector engine. So we would get AGG in browsers too :-) ... 
unfortunatelly, licence change ruins the effort

We can assume, Cairo is distributed under LGPL, right? If so, it 
becomes 
really incompatible with the GPL. For now I'd suggest you 
to keep using AGG 
2.4, at least until we can come up with a better 
legal solution. Basically, 
I want to prevent some 
commercial monster corporations" from free use of 

AGG. But I do want the Linux world to keep using it for free. I'm 
not quite 

sure how well LGPL protects from uncontrolled free commercial use; 
if it 

does, I may re-think and switch to the LGPL. But I'm not willing 
to keep 

using totally free, BSD-like licences in future versions. Ideally, 
I'd like 
to come up with some kind of a QT-like licensing scheme."

yes, with Cairo crap instead of AGG, right? :-)

JavaScript doesn't have access to Cairo directly in any browser. 
JavaScript is not anywhere near as fast as Java yet.

shadwolf - the question is, if AGG is capable enough to allow all 
possible renderings. But let's hope it is. Mozilla foundation is 
going to use Cairo library. Hopefully Maxim will stil improve on 
AGG ...

so maybe AGG is not originally designed to work with SVG? OK, we 
can integrated Cairo library then too :-)

the question is - AGG for vectors, is one of two best free libraries 
- Cairo and AGG ... so - how is fmod quality wise? Is there any better, 
smaller library to have?

Uhm, as I posted in Linux group, many systems are targetting its 
future towards vectore usage. Co-author of KDE 4 blogged about how 
fast Qt 4 based vector pipeline is, and it seems other engines can't 
stand the competition. Of course he generated some noise, as Cairo 
fanboys did not like it :-) http://zrusin.blogspot.com/So I looked 
at http://www.antigrain.com, to see what is new with AGG. It seems 
to me, that it is not good for RT - they are changing licence for 
any new version to GPL

pity AGG is no more developed. There is no other option currently. 
Everybody else uses Cairo, but this is crap with more than 1MB size. 
Amanith seems interesting too, but commercial. Hopefully Maxim updates 
AGG at least to keep the trends. But so far - AGG is very high quality, 
so nothing to worry about for quite some time....

Pekr: I guess some of the crap in the IMB of Cairo is to support 
hardware acceleration and printing.

Thanks. ACW.r coded by hand, but helped by the fact that I used a 
real map as a background image to trace over (the compass rose method 
of indicating paths is really easy ... "start in Cairo, go 3 hexes 
north, etc"). By comparison, I spent days trying to get the same 
results with CC3 (Campaign Cartographer 3) ... but I'm only a casual 
CC3 user.

Maxim, no problem, I have not much time either now so feel free to 
clarify any time later.

I was just wondering what you are looking for to satisfy your needs.

And of course, you cannot request functionality of big complex 3D 
systems which are usually fat high-level layers over  low level graphics 
libraries.

You should think about the DRAW at the level of graphic library api, 
not application layer.

So I more awaited comparison with OpenGL, DIrectX, Cairo, Qt , Java2d 
 and so on. Anyway, I'm curious about your  examples....

Also I don't understand what is so wrong on using dialect as an interface 
when Rebol should be the case where working with blocks, dialects 
etc. should be a plus.

For example If you prefer interface based on function calls over 
dialect the I'd like to know what benefits you see in that approach 
etc.

the developer states that his technique gives better results than 
Cairo and AGG

no, Cairo ... but AGG is still better than Cairo, so why to worry? 
And even if Max does not develop it further, maybe AGG community 
will come with some other improvements ...

I see AmigaOS4.1 uses cairo

I see Cairo has both PS and PDF as output targets ... which sounds 
really good to me!

http://cairographics.org/manual/cairo-ps-surface.html

Graham, I suspect Cairo takes on tasks other than rasterization, 
which is why it has PDF/PS outputs. AGG doesn't do that and shouldn't 
be doing that anyway.

There will be plenty of ability to print, but surely there are smarter 
ways to go about that than by bringing in a huge monolithic library 
like Cairo.

How big is Cairo lib? IIRC it was over 1MB? I agree with Robert - 
let's finish what we have. Let's see, what enhancements we can get 
in. AGG is still a cool library, being used by MANY projects. Just 
becuase Mozilla honchos could not do any better and choosed Cairo 
as mostly a political decision (because of author's involvement in 
the project) does not mean Cairo is any better ...


Apart from that, and as Robert says - in future, we can eventually 
replace it.

but i can be wrong the cairo context is maybe just a transparent 
back grounded abstracted widget you can clip to any face

on a fonctionnality ground cairo have good point

i think cairo can be fun  but then the question is always the same 
will the dialect build to interface it with rebol will cover the 
whole thing or just cover the ground capabilities

i like the path thing in cairo ...

using the  cairo path layer you can imagine multi layer drawing  
something like photoshop's "calques" (sorry it's french lets say 
masks)

So, if you created a rendering surface or whatever in Cairo, can 
you then ask another Rebol process to access it?

the real true ask is rebol is slow to evolve so does cairo will evolve 
betwin 2 rebol release or does it will go to abandonedwar after 2 
years  ?

So, one could use AGG for somethings like a GUI and then use Cairo 
for display postscript

yeah ... but cairo doesn't seems bad at all

i would say  cairo isn't bad

hum cairo glyph api is linked to pango ?

my goal is to allow an dynamic linking of any external gfx engine 
within the current system.   hopefully DirectX, Cairo and ImageMagic 
integrations will also be possible, but I have no idea about their 
API so it might still be a pipe dram at this point.

I have added hooks for Cairo and Image Magic too.  (though they aren't 
implemented in any ways whatsoever).

BrianH thank you :) ... As a side note GDI is deprecated and abandonned 
massively on hardware level... but Gfx libs like Cairo support directX 
rendering hardware accelaration or OpenGL depending the plateform 
... I'm not quite the super exper on the topic. But i know that's 
a tendency to move back graphical content to the GPU  and not only 
when it comes to 3D rendering ...

Well, latest AGG version (2.5) is distributed under GPL, development 
has stopped in 2006, it doesn't support hardware acceleration AFAIK, 
so it's a no-go. Cairo seems like a more modern graphic vector engine. 
Anyway, it is open to any contributor, as I don't plan to work personally 
on a View-like engine for Red.

There are basically four options: AGG, Fog, Cairo and Skia

I was always unimpressed with Cairo. If you want a full-featured 
library, Skia looks better

Comparing against Cairo is like taking candy from a kid :-)

I also want to know if rendering quality in Skia is as good as in 
AGG. It sucks in Cairo, or at least it always did. Fog is likely 
to be as good as AGG, because it builds on the same principles