New Cairo renderer (for PDF export)
Hi all,
I committed a part of my GSoC work, a Cairo-based simple, naiv SVG renderer which will help to have better quality PDF export. It can be found in extension/internal/cairo-render* and there's a new showGlyphs function in class Layout (Layout-TNG-Output.cpp). Its raster output can be considered usable and might be useful for testing Cairo vs. libnr rendering performance. The new output types in 'Save As' are: 'Cairo PDF experimental' and 'Cairo PNG' (this doesn't have any options yet unlike the PNG export function). Currently the renderer doesn't have any obvious optimization like creating surfaces with only the needed bbox size and not of the full size of the output. It needs Cairo 1.2 since it uses cairo_pop/push_group calls so I have wrapped the code around HAVE_CAIRO_PDF which ensures the correct API version. The SVG element-specific rendering methods are in static methods named like sp_flowtext_render so they could be easily put into the virtual methods of the objects representing these elements in other source files. Please consult the source code for more details (cairo-renderer.cpp). The Cairo-specific rendering part can be found in cairo-render-context.cpp. This renderer supports clipping (objectBoundingBox clipping doesn't work -- does anyone have an idea what could be wrong?), masking, and surface patterns in SVG, among the other straightforward things. I wanted to have more things implemented properly but since September I didn't really have much time to spend on this so I decided to release it in its current state so you can tear it apart :) Unfortunately I haven't finished the Cairo-PDF patches for it yet. I have a working version which is quite unstable with text (isn't shown in layers except for the 'root' layer) and images and which supports masking with constant alpha. I cannot release it because it's such a mess at this point. I know the main problem with this exporter is the fact that first the support needs to be built into Cairo in order to take advantage of this exporter and that won't happen overnight, but at least now Inkscape has a simple Cairo-based SVG rendering backend. I hope to get the Cairo-PDF patches into Cairo 1.4.x. Any ideas, comments regarding the subject are welcome.
Cheers, miklos
Miklós Erdélyi wrote:
Any ideas, comments regarding the subject are welcome.
Looks like we are still having a few troubles on win32.
Aaron Spike
i686-pc-mingw32-g++ -Wall -O3 -g -mms-bitfields -DVERSION="0.45+devel" -DXP_WIN -D_INTL_REDIRECT_INLINE -DHAVE_CONFIG_H -DWITH_INKBOARD -I. -I.. -I../.. -I../cxxtest -DGLIBMM_DLL -Ic:/gtk28/include/glibmm-2.4 -Ic:/gtk28/lib/glibmm-2.4/include -Ic:/gtk28/include/gtkmm-2.4 -Ic:/gt k28/lib/gtkmm-2.4/include -Ic:/gtk28/include/gdkmm-2.4 -Ic:/gtk28/lib/gdkmm-2.4/include -Ic:/gtk28/include/pangomm-1.4 -Ic:/gtk28/include/at kmm-1.6 -Ic:/gtk28/include/cairo -Ic:/gtk28/include/sigc++-2.0 -Ic:/gtk28/lib/sigc++-2.0/include -Ic:/gtk28/include/gtk-2.0 -Ic:/gtk28/lib/gt k-2.0/include -Ic:/gtk28/include/atk-1.0 -Ic:/gtk28/include/pango-1.0 -Ic:/gtk28/include/glib-2.0 -Ic:/gtk28/lib/glib-2.0/include -Ic:/gtk28/ include -Wno-comment -Ic:/gtk28/perl/lib/CORE -Ic:/gtk28/python/include -Ic:/gtk28/include/loudmouth-1.0 -Ic:/gtk28/include/libxml2 -Ic:/gtk2 8/include/freetype2 -I. -Ialgorithms -Iapplication -Idebug -Idialogs -Idisplay -Idom -Idom/io -Idom/js -Idom/js/fdlibm -Idom/odf -Idom/svg - Idom/util -Iextension -Iextension/implementation -Iextension/internal -Iextension/internal/libwpg -Iextension/script -Igraphlayout -Ihelper - Iinkjar -Iio -Ijabber_whiteboard -Ijabber_whiteboard/dialog -Ilibavoid -Ilibcola -Ilibcroco -Ilibnr -Ilibnrtype -Ilibvpsc -Ilibvpsc/pairinghe ap -Ilivarot -Ipedro -Iremoveoverlap -Isvg -Itrace -Itrace/potrace -Itraits -Iui -Iui/dialog -Iui/view -Iui/widget -Iutil -Iwidgets -Ixml -c -o extension/internal/cairo-render-context.o extension/internal/cairo-render-context.cpp extension/internal/cairo-render-context.cpp:74:22: error: cairo-ft.h: No such file or directory extension/internal/cairo-render-context.cpp: In member function 'bool Inkscape::Extension::Internal::CairoRenderContext::renderGlyphtext(Pang oFont*, const NRMatrix*, const std::vector<Inkscape::Extension::Internal::CairoGlyphInfo, std::allocatorInkscape::Extension::Internal::Cairo GlyphInfo >&, const SPStyle*)': extension/internal/cairo-render-context.cpp:1262: error: 'cairo_ft_font_face_create_for_pattern' was not declared in this scope make[1]: *** [extension/internal/cairo-render-context.o] Error 1 make[1]: Leaving directory `C:/src/inkscape_svn/src' make: *** [all] Error 2
Hello Miklos,
first thanks for all your work.
It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf. I filed a bug with a small sample. I did not looked into any code but I think once we have the blur we have to export to pdf as well until the next release.
http://sourceforge.net/tracker/index.php?func=detail&aid=1584935&gro...
HTH,
Adib. ---
Miklós Erdélyi schrieb:
Hi all,
I committed a part of my GSoC work, a Cairo-based simple, naiv SVG renderer which will help to have better quality PDF export. It can be found in extension/internal/cairo-render* and there's a new showGlyphs function in class Layout (Layout-TNG-Output.cpp). Its raster output can be considered usable and might be useful for testing Cairo vs. libnr rendering performance. The new output types in 'Save As' are: 'Cairo PDF experimental' and 'Cairo PNG' (this doesn't have any options yet unlike the PNG export function). Currently the renderer doesn't have any obvious optimization like creating surfaces with only the needed bbox size and not of the full size of the output. It needs Cairo 1.2 since it uses cairo_pop/push_group calls so I have wrapped the code around HAVE_CAIRO_PDF which ensures the correct API version. The SVG element-specific rendering methods are in static methods named like sp_flowtext_render so they could be easily put into the virtual methods of the objects representing these elements in other source files. Please consult the source code for more details (cairo-renderer.cpp). The Cairo-specific rendering part can be found in cairo-render-context.cpp. This renderer supports clipping (objectBoundingBox clipping doesn't work -- does anyone have an idea what could be wrong?), masking, and surface patterns in SVG, among the other straightforward things. I wanted to have more things implemented properly but since September I didn't really have much time to spend on this so I decided to release it in its current state so you can tear it apart :) Unfortunately I haven't finished the Cairo-PDF patches for it yet. I have a working version which is quite unstable with text (isn't shown in layers except for the 'root' layer) and images and which supports masking with constant alpha. I cannot release it because it's such a mess at this point. I know the main problem with this exporter is the fact that first the support needs to be built into Cairo in order to take advantage of this exporter and that won't happen overnight, but at least now Inkscape has a simple Cairo-based SVG rendering backend. I hope to get the Cairo-PDF patches into Cairo 1.4.x. Any ideas, comments regarding the subject are welcome.
Cheers, miklos
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2006-10-26 at 10:46 +0200, Adib Taraben wrote:
It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf.
Cairo doesn't directly support blur, and as far as I know won't ever.
That doesn't mean we can't do blur with a Cairo-based renderer, of course, but it does mean we'd need to implement it ourselves using an intermediate image surface.
The bigger problem is that there's no way to represent blur in PDF. If you want blur in exported PDFs, you'll have to resort to rasterizing blurred objects at some fixed resolution.
-mental
On Thu, 2006-10-26 at 12:41 -0400, MenTaLguY wrote:
On Thu, 2006-10-26 at 10:46 +0200, Adib Taraben wrote:
It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf.
Cairo doesn't directly support blur, and as far as I know won't ever.
That doesn't mean we can't do blur with a Cairo-based renderer, of course, but it does mean we'd need to implement it ourselves using an intermediate image surface.
The bigger problem is that there's no way to represent blur in PDF. If you want blur in exported PDFs, you'll have to resort to rasterizing blurred objects at some fixed resolution.
cworth, maybe you could chime in on this and the best way to handle this :)
Jon
On Thu, 26 Oct 2006 10:54:18 -0700, Jon Phillips wrote:
On Thu, 2006-10-26 at 12:41 -0400, MenTaLguY wrote:
On Thu, 2006-10-26 at 10:46 +0200, Adib Taraben wrote:
It seems that Inkscape does not export the blur to cairo pdf nor cairo-experimental pdf.
Cairo doesn't directly support blur,
Correct. Cairo does not supply a blur operation.
and as far as I know won't ever.
I've wanted to have a blur operation in cairo for a long time. I regard it as one of the last few "obviously needed" things to have in cairo.
And some of cairo's backends, (such as the XRender-using xlib backend), have filter support which would allow cairo to get access to hardware-accelerated blur when available. So that kind of thing is a very important reason to get this API into cairo rather than forcing applications to drop to software for it.
That doesn't mean we can't do blur with a Cairo-based renderer, of course, but it does mean we'd need to implement it ourselves using an intermediate image surface.
Yes, that's the "drop to software" path. It does exist now, (and will always), but I would hope it would not be the only solution forever.
Basically, we just need someone to cook up a good API that "fits" cairo for supporting blur and other filter types.
The bigger problem is that there's no way to represent blur in PDF. If you want blur in exported PDFs, you'll have to resort to rasterizing blurred objects at some fixed resolution.
Yes, that's a pain. But once we put the blur support into cairo we can at least just solve this once there and every application can use it without having to reinvent it.
cworth, maybe you could chime in on this and the best way to handle this :)
I hope this helps. Here's a pointer to the most recent conversation we (MentalGuy and myself) had about this on the cairo list:
http://lists.freedesktop.org/archives/cairo/2006-March/006577.html
There are some API suggestions there, but we've never seen an attempt at an implementation yet.
Anyone want to give it a try? It would be a very beneficial thing to have.
-Carl
On 10/27/06, Carl Worth wrote:
Correct. Cairo does not supply a blur operation.
BTW, according to Save As/Save As Copy dialog there are three PDF exporters in Inkscape now, two of them rely on Cairo and have different sets of features. E.g. the first one saves text and doesn't save clipping path, the second saves clipping path but drops text.
Which one do you keep for 0.45?
Alexandre
On Fri, 2006-10-27 at 15:45 +0400, Alexandre Prokoudine wrote:
BTW, according to Save As/Save As Copy dialog there are three PDF exporters in Inkscape now, two of them rely on Cairo and have different sets of features. E.g. the first one saves text and doesn't save clipping path, the second saves clipping path but drops text.
Which one do you keep for 0.45?
Ah... can we merge them? Seriously. I don't think the users will like that state of affairs very much...
-mental
On Fri, 2006-10-27 at 14:59 -0400, MenTaLguY wrote:
Ah... can we merge them? Seriously. I don't think the users will like that state of affairs very much...
In fact, frankly I think we should block the release until we've got a single PDF exporter with all the functionality rolled in.
The state of PDF export was one of the biggest complaints when we did the 0.44 release, and if it's even worse in 0.45 we'll be letting a lot of people down.
-mental
On Fri, 2006-10-27 at 15:18 -0400, MenTaLguY wrote:
On Fri, 2006-10-27 at 14:59 -0400, MenTaLguY wrote:
Ah... can we merge them? Seriously. I don't think the users will like that state of affairs very much...
In fact, frankly I think we should block the release until we've got a single PDF exporter with all the functionality rolled in.
The state of PDF export was one of the biggest complaints when we did the 0.44 release, and if it's even worse in 0.45 we'll be letting a lot of people down.
-mental
What needs to be done to get this sorted? Who is working on this? Can we break it into bite sized chunks to knock this out? Let's do it if we can concretize the tasks....
Jon
On Fri, Oct 27, 2006 at 03:18:02PM -0400, MenTaLguY wrote:
On Fri, 2006-10-27 at 14:59 -0400, MenTaLguY wrote:
Ah... can we merge them? Seriously. I don't think the users will like that state of affairs very much...
In fact, frankly I think we should block the release until we've got a single PDF exporter with all the functionality rolled in.
If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.
Bryce
On Fri, 2006-10-27 at 13:16 -0700, Bryce Harrington wrote:
If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.
I guess the thing to do is to do up a feature matrix to identify the features each PDF backend supports, and merge features from the other two PDF backends into the more complete cairo-based one. The matrix will also serve as a checklist to know when we're done, and for testing.
Alexandre, would you be willing to supervise this effort? Since I was the one making all the promises on Slashdot that we'd fix the PDF stuff for 0.45, I'll help out as much as I can, but I know my attention's going to be pretty divided.
-mental
On Fri, 2006-10-27 at 13:16 -0700, Bryce Harrington wrote:
If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.
Well, since Alexandre hasn't expressed interest in heading this up, I guess I'll do it. It's a pretty bad situation to begin with, but after all those Slashdot posts, it's also a question of personal honor for me.
So, first step. Compile that feature matrix. I'll prep a spreadsheet.
-mental
On Sat, Oct 28, 2006 at 03:26:35PM -0400, MenTaLguY wrote:
On Fri, 2006-10-27 at 13:16 -0700, Bryce Harrington wrote:
If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.
Well, since Alexandre hasn't expressed interest in heading this up, I guess I'll do it. It's a pretty bad situation to begin with, but after all those Slashdot posts, it's also a question of personal honor for me.
So, first step. Compile that feature matrix. I'll prep a spreadsheet.
Cool, sounds good. We'll pause the release to allow for time to be focused on this. I bet combining the various efforts into one will produce a very killer feature. :-)
Bryce
On Sat, Oct 28, 2006 at 03:26:35PM -0400, MenTaLguY wrote:
On Fri, 2006-10-27 at 13:16 -0700, Bryce Harrington wrote:
If we do this (and I agree it makes sense), then we must have a plan on how to do it, and someone to be point person on the effort for making the decisions. If someone can identify these two things, then we can make this a hard block on the release.
Well, since Alexandre hasn't expressed interest in heading this up, I guess I'll do it. It's a pretty bad situation to begin with, but after all those Slashdot posts, it's also a question of personal honor for me.
So, first step. Compile that feature matrix. I'll prep a spreadsheet.
I went back through this thread for todo items. Most of these are from Miklos' initial email, so perhaps he has additional suggestions for what needs done...?
* Identify feature differences between the three PDF implementations
* Cairo-based PDF renderer - Add optimizations like creating surfaces with only the needed bbox size, rather than the full size of the output - objectBoundingBox clipping doesn't work... need to find out why - Cairo-PDF patches are not yet finished. These will need to be incorporated into Cairo. - Text is quite unstable (isn't being shown except in 'root' layer) - Images are unstable - Masking is supported only with constant alpha * Ensure blur works with export to pdf via rasterizing of blurred objects in a fixed resolution
Any other things?
Could someone suggest ways to test everything that'll need to be supported?
It sort of sounds like while it would be nice to use Cairo+GeGL for blur support, since GeGL hasn't had a formal release and hasn't identified a stable API yet, that could be a challenge. Besides, if PDF doesn't support effects and we have to rasterize such things anyway, it may as well be done internally for now.
Bryce
On Sat, 2006-10-28 at 13:18 -0700, Bryce Harrington wrote:
- Identify feature differences between the three PDF implementations
Here's what I've got so far, though looking at the issue list for the cairo stuff, it looks like I could stand to add some additional features to the spreadsheet.
Feature Extension "PDF" (pdf-out.cpp) "Cairo PDF" (cairo-pdf-out.cpp) "Cairo PDF experimental" (cairo-renderer-pdf-out.cpp) stroke-opacity (solid) yes yes yes fill-opacity (solid) yes yes yes linearGradient (fill) yes incorrect incorrect linearGradient (stroke) no incorrect incorrect radialGradient (fill) yes incorrect incorrect radialGradient (stroke) no incorrect incorrect stop-opacity no yes yes image yes yes yes fill-opacity (gradient) no yes yes stroke-opacity (gradient) no yes yes text (as text) no no no text (as path) yes yes yes flowText (as text) no no no flowText (as path) yes yes yes opacity (path) yes yes yes opacity (image) no yes yes opacity (fill +stroke) incorrect incorrect incorrect opacity (group) incorrect incorrect incorrect
It looks like today, with stock Cairo 1.2 in Ubuntu, the general results are better with the Cairo PDF backends than the "legacy" PDF backend.
However, given the features I tested above, we've got three problems:
1. Gradient rendering problems resulting from the use of CAIRO_EXTEND_NONE instead of CAIRO_EXTEND_PAD (although we'll also need to see whether CAIRO_EXTEND_PAD is supposed by the stuck PDF backend...).
2. There's no option to embed text as text.
3. _ALL_ the PDF implementations seem to have been written with the bogus idea that alpha compositing is commutative/distributive. Compositing two rectangles with 0.5 alpha is NOT the same thing as compositing a group (of two rectangles) having 0.5 alpha. Similarly with fills and strokes, which should be treated as if there were a group containing a fill object and a stroke object, rather than simply multiplying fill-opacity and stroke-opacity by the object opacity.
- Cairo-based PDF renderer
- Add optimizations like creating surfaces with only the needed bbox size, rather than the full size of the output
- objectBoundingBox clipping doesn't work... need to find out why
- Cairo-PDF patches are not yet finished. These will need to be incorporated into Cairo.
- Text is quite unstable (isn't being shown except in 'root' layer)
- Images are unstable
- Masking is supported only with constant alpha
Can Miklós or somebody separate these into the issues that need to be addressed at the Cairo level, and the issues which need to be addressed in our own backend?
- Ensure blur works with export to pdf via rasterizing of blurred objects in a fixed resolution
Unless someone's feeling extra motivated, we'll probably have to punt on PDF blur for this release.
Could someone suggest ways to test everything that'll need to be supported?
doc/PDF Feature Matrix.svg has test cases for everything on the corresponding spreadsheet. I'm afraid that none of the Open Source PDF viewers I've tried so far have complete enough support for PDF to do the entire test suite correctly, so the test results will have to be checked in Adobe Acrobat Reader.
-mental
On 10/28/06, MenTaLguY wrote:
Well, since Alexandre hasn't expressed interest in heading this up, I guess I'll do it. It's a pretty bad situation to begin with, but after all those Slashdot posts, it's also a question of personal honor for me.
Well, I couldn't express interest simply because I was away from any Internet-aware computer last 36 hours :) You have brought discussion to the point where I couldn't anyway :)
Alexandre
On Thu, 2006-10-26 at 16:02 -0700, Carl Worth wrote:
hope this helps. Here's a pointer to the most recent conversation we (MentalGuy and myself) had about this on the cairo list:
http://lists.freedesktop.org/archives/cairo/2006-March/006577.html
There are some API suggestions there, but we've never seen an attempt at an implementation yet.
Is Keith now willing to accept an API which doesn't entail a full software implementation of GLSL up-front? That's basically why I finally gave up.
[ See the (belated) continuation of the thread here:
http://lists.freedesktop.org/archives/cairo/2006-September/007760.html ]
Aside from that though, since we had these discussions, I realized that perhaps we should be looking at is the potential for cairo/GEGL integration. It's possible that cairo doesn't really need a full-fledged effects API, just some hooks to allow better interoperation with stuff like GEGL.
-mental
On Fri, 27 Oct 2006 15:13:53 -0400, MenTaLguY wrote:
Is Keith now willing to accept an API which doesn't entail a full software implementation of GLSL up-front? That's basically why I finally gave up.
[ See the (belated) continuation of the thread here:
http://lists.freedesktop.org/archives/cairo/2006-September/007760.html ]
Ah! Well I happened to agree with you on that thread, and my opinion matters much more than Keith's here. He's certainly not about to veto anything we want to do with cairo.
I read his stuff as "you might end up wanting more than this anyway", which I can agree with. But I don't think we need to start with the full-fledged programmable shaders thing before we can provide something as simple as a blur.
Aside from that though, since we had these discussions, I realized that perhaps we should be looking at is the potential for cairo/GEGL integration. It's possible that cairo doesn't really need a full-fledged effects API, just some hooks to allow better interoperation with stuff like GEGL.
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
-Carl
On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?
-mental
On Fri, Oct 27, 2006 at 05:51:56PM -0400, MenTaLguY wrote:
On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?
Probably you'll want to encourage Pippin to put out an official release first. (I think he's been holding off until it's more stable.)
Bryce
On Fri, 27 Oct 2006 17:51:56 -0400, MenTaLguY wrote:
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design.
That all sounds fairly reasonable.
Is this a wheel we need to reinvent in cairo?
We don't need to, of course. I'll just leave it to whoever does the work to decide the best place to do it, (which is how it always works anyway).
-Carl
On 10/27/06, MenTaLguY <mental@...3...> wrote:
On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.
GEGL doesn't yet implement all of the SVG raster effects. Some are implemented, some under way and others waiting for someone to code them. I've also considered making the XML parser for GEGL compositions support reading SVG filters (and reuse them in the composition trees already supported by the XML parser.)
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?
Cairo wouldn't necessarily want to reinvent the entire wheel, but at least provide means to use the commonly desired filters that lend themselves easily for hardware acceleration. To me GEGL as a dependency for cairo seems top-heavy.
Optimization has not been a priority for GEGL yet, And it is designed to be able to cope with larger than RAM images with processing done with 128bit/pixel (32bit floating point/component). Lesser demands that can be optimized are taking a back seat to get a reference implementation with readable code working first.
The reason there is no release of GEGL yet, is that time has not been found to verify exactly what APIs should be exported, and how to present that API. There is working test code now, it exercises and demands expansion of the public API, this will probably help solidify the needed APIs.
Once GEGL itself works well enough, with a stable API. Focus will probably be diverted to adding support for registering optimized paths for different pixel formats (where some of the formats might indicate GPU processing).
/Øyvind K.
On Sun, 2006-10-29 at 12:04 +0100, Øyvind Kolås wrote:
On 10/27/06, MenTaLguY <mental@...3...> wrote:
On Fri, 2006-10-27 at 12:58 -0700, Carl Worth wrote:
That may be too. But GEGL's going to be all-software, right? (At least for now). I agree we don't need to provide an API in cairo to be able to do totally arbitrary effects, but when something like a convolution filter is _so easy_ for almost any hardware to do, it's a shame that cairo isn't exporting any easy way to get at that.
Yeah... unfortunately for Inkscape, we still need to implement the rest of the SVG raster effects as well. If I understand correctly, GEGL already provides them, so I'd tend to choose it over re-implementing them manually. At that point we may as well use GEGL for blur too, rather than attempting some kind of messy mixed-mode arrangement.
GEGL doesn't yet implement all of the SVG raster effects. Some are implemented, some under way and others waiting for someone to code them. I've also considered making the XML parser for GEGL compositions support reading SVG filters (and reuse them in the composition trees already supported by the XML parser.)
But, the other part of it is that the GEGL API does seem amenable to acceleration if someone wanted to do it now, and the architecture of a cairo-based filter API is likely going to have to be similar in design. Is this a wheel we need to reinvent in cairo?
Cairo wouldn't necessarily want to reinvent the entire wheel, but at least provide means to use the commonly desired filters that lend themselves easily for hardware acceleration. To me GEGL as a dependency for cairo seems top-heavy.
Hye, but adding GEGL as a dependency to CAIRO sure would get it into a lot hands quickly ;) Ok, I'm not really advocating this...just saying...
<snip />
participants (9)
-
Aaron Spike -
Adib Taraben -
Alexandre Prokoudine -
Bryce Harrington -
Carl Worth -
Jon Phillips -
MenTaLguY -
Miklós Erdélyi -
Øyvind Kolås