Cairo & Silverlight
dlac...@erasme.org
AntiGrain. But don't you think Cairo is a better alternative since we
already need (and have) a binding for it with mono and that we gona
share its perf optimisation with app like Gtk and Gecko.
Else, implementing Silverlight on top of mono will be good but what is
the openess of Silverlight ? Do we have public and free Silverlight
specification (and where) ? We need the Silverlight XAML spec but also
the class that we have to expose to langage like C# (and check that we
are free to implement them).
If you can have all of this, I'd love to participate to such project.
Miguel de Icaza
> You have wrote that Silverlight might be implemented on top of
> AntiGrain. But don't you think Cairo is a better alternative since we
> already need (and have) a binding for it with mono and that we gona
> share its perf optimisation with app like Gtk and Gecko.
Well, a few things:
We would not likely be using the managed binding, most likely we will
do
all the rendering in unmanaged code and merely drive the rendering
engine
from managed code.
This is at least how its supposed to work on the big WPF, I have not
looked
at all the details on tiny-WPF, but it would also probably reduce the
integration
pain points with something like the Fluendo Codecs of ffmpeg.
Agg is very fast, while Cairo is still being tuned, and Agg has
support for many
more pixel formats and is really a "toolkit" to build graphic systems,
a toolkit
that we can more easily tune or provide alternative implementations of
chunks
of it as we deem necessary.
> Else, implementing Silverlight on top of mono will be good but what is
> the openess of Silverlight ? Do we have public and free Silverlight
> specification (and where) ? We need the Silverlight XAML spec but also
> the class that we have to expose to langage like C# (and check that we
> are free to implement them).
At this point Silverlight Alpha 1.1 comes with very little
documentation, I read a lot
of it on the plane last night, and it is obviously missing a *lot*,
the documentation
barely talks about their Javascript binding, so it is an area where
they are not yet
done.
The tags for Xaml on the other hand seem to be fairly well specified,
the trick of course
is the C# implementation.
> If you can have all of this, I'd love to participate to such project.
We could certainly use your help, am starting some discussions as to
how we will
get from point A and point B, and should have a plan written up on the
next few
weeks.
Miguel.
Michael Hutchinson
> Agg is very fast, while Cairo is still being tuned, and Agg has
> support for many
> more pixel formats and is really a "toolkit" to build graphic systems,
> a toolkit
> that we can more easily tune or provide alternative implementations of
> chunks
> of it as we deem necessary.
But what about the AGG license? It would be awkward if Mono could only
legally support GPL Silverlight apps, or if we had to develop and
maintain a branch of AGG 2.4.
Michael Hutchinson
> support for many
> more pixel formats and is really a "toolkit" to build graphic systems,
> a toolkit
> that we can more easily tune or provide alternative implementations of
> chunks
> of it as we deem necessary.
But what about the AGG license? It would be awkward if Mono could only
Miguel de Icaza
I think we would have to develop and maintain Agg 2.4.
There are various folks in the Agg community that are interested in this approach, considering that they can not easily move to Agg 2.5.
Miguel.
EmmanuelP
> support for many
> more pixel formats and is really a "toolkit" to build graphic systems,
> a toolkit
> that we can more easily tune or provide alternative implementations of
> chunks
> of it as we deem necessary.
This mail from Carl Worth suggests that Agg isn't that faster:
http://www.xaraxtreme.org/maillists/archive/dev/dev_022007/msg00131.html
Cairo also provide a very nice backend infrastructure with the
possibility of hardware accelerated rendering and vector format
outputs .
And if you have to improve cairo, you'll can do that with all the
existing community, where with Agg you'll have to create a fork.
asbjornu
> Cairo also provide a very nice backend infrastructure with the
> possibility of hardware accelerated rendering and vector format
> outputs .
>
> And if you have to improve cairo, you'll can do that with all the
> existing community, where with Agg you'll have to create a fork.
I agree that Cairo seems like a better choice. Sure, AGG fits better
functionally now, but with the license and (future) maintaining
problems, I'd say Cairo will surely be a better choice in the long
run. It would be nice if Miguel could dive into the concrete benefits
AGG have over Cairo today and how those compare to the benefits Cairo
has with regard to licensing and maintenance both now and in the
future.
Miguel de Icaza
> I agree that Cairo seems like a better choice. Sure, AGG fits better
> functionally now, but with the license and (future) maintaining
> problems, I'd say Cairo will surely be a better choice in the long
> run. It would be nice if Miguel could dive into the concrete benefits
> AGG have over Cairo today and how those compare to the benefits Cairo
> has with regard to licensing and maintenance both now and in the
> future.
It is just hard to beat MIT X11 licensed code, specially if we ever
are approached to relicense for embedded use. Cairo switch to LGPL/
MPL might be problematic.
Yes, we would have to maintain Agg 2.4 for that though.
Miguel.
Miguel de Icaza
> Agg is very fast, while Cairo is still being tuned, and Agg has
> support for many
> more pixel formats and is really a "toolkit" to build graphic systems,
> a toolkit
> that we can more easily tune or provide alternative implementations of
> chunks
> of it as we deem necessary.
This mail from Carl Worth suggests that Agg isn't that faster:
http://www.xaraxtreme.org/maillists/archive/dev/dev_022007/msg00131.html
Cairo also provide a very nice backend infrastructure with the
possibility of hardware accelerated rendering and vector format
outputs .
And if you have to improve cairo, you'll can do that with all the
existing community, where with Agg you'll have to create a fork.
dlac...@erasme.org
Agg seems to be a nice rendering system. The resulting image looks
good. But it is a C++ library. Is it not a problem for a Mono
binding ? I have seen that a binding exist on Windows but the code is
not available (at least I have not found it). Agg also use a lot a C++
template system which can be no so simple for a binding.
But, one good think is that it have few dependencies which allow
simple port on embended devices. Agg does not depend upon OpenGL and I
hope this a possibilities to have a multi-thread rendering system and
use the power of multi-core processor. This can be a way to have good
perf with Agg and less constraint than OpenGL.
This is a really interesting project which will certainly have
important consequences on the web. I'd love to participate. I am not a
master chief programer but if I can help, you known were to find me.
Miguel de Icaza
Agg seems to be a nice rendering system. The resulting image looks
good. But it is a C++ library. Is it not a problem for a Mono
binding ? I have seen that a binding exist on Windows but the code is
not available (at least I have not found it). Agg also use a lot a C++
template system which can be no so simple for a binding.