A proposal for the filter tool (and the others)
Hi!
First, I have to say that I do like inkscape, that I use everyday, sometimes just for fun. But, like all free softwares, it has few problems. Some are not important, others may become disabling. Obviously filters belong to the second category. Not because there are buggy (they aren't), but because the rendering engine is just too slow, when you are using few "big" filters in a big picture and you want to export in a big size, it takes centuries. I'm not complaining, I take a coffee during the export, but well... And it has other few problems like "what you see is not really what you get". More than this, useful features are missing: using filter in another filter, disable/mask an effect without remove it, things like that. Again, I'm not complaining, developing a soft like Inkscape is a hard stuff, and you, developers, do a great job.
First remark: When we watch filter structure closely, it's very similar to "path effects" and even "stroke" or "shape". You have an object that you change with effects: colors, shape, style and so on.
For fun, again, I use UDK (Unreal Development Kit) to develop games (mostly to understand how they work). I suppose that many people know this kit, if not, search "Epic Unreal Development Kit". In this kit, like all other game development kits, you apply materials to 3D objects, that are basically textures improved with a lot of effects to fake light, glow, deepness, relief and so on. To create these effects, you use a GUI (attached picture) where you start with the 3D object (the big rectangle on the left) and put on it effects, which can be modified by sub-effects, which can be etc. The attached picture is obvious, and shows clearly how it works, I think.
What do I want to say? I think that many tools/operations of Inkscape can be done via a GUI like this. - Everything can be a "basic" object: line, stroke, shape, geometric shape, group, clone. - On these objects you can change 4 things: shape (fill or edge) and color (fill of edge). That's all. - For the effects available you find all tools available in "filter" or "path effects", like bending, matrix operations, styles... - So when I want to put a "object on fire" effect on a circle, I click on it, a window like the attached picture is opened, I can see the object "circle" on the left, and few effect already attached, like fill color and the type of the stroke for the edge. I'm choosing the filter "on fire" in the library, and put it. I'm using dashes to tell where it's used, configuring it, closing the GUI, and the effect appears. - You see also what I mean: With this system you can create you own effects and use them like "basic effect" in other filters (missing feature in the actual filter tool). - It's the same for the objects themselves. For instance you could have a 'group' with effects (filter, transparency,...) with many sub-objects/shapes with their own effects. - Many existing GUI/tools in Inkscape could disappear with this one, and changed by "basic effect objects" attached on shapes/strokes: Tools filter, path effect, color, text, transform, tiling, distribute, 'rows and columns'...
I do know that the work for this is huge (another summer google contest?). You have to start from scratch, basically. And I read somewhere that for futures versions, Inskcape will merge "filter tool" and "path transform tool" in order to unify all this stuff. I agree, it's essential for my point of view, if you want to continue improving your great tool without too much trouble. My idea can be useless, because the concept doesn't fit with the .svg specifications (I'm thinking about colors or edge thickness, for example, that are directly in the object definition, while filters are stored in svg:defs). Or compatibility with other softs that reading .svg. Or maybe you don't care. But implement this and many expensive professional vectorial tools will become "old-school" immediately ^^ ...
Sorry for the length. And sorry if I seemed arrogant or smug, it wasn't my intention, English is not my native language. I just had this idea this morning.
My 2 cents, François.
PS: About the actual filter tool: Maybe I missed something, but the tool "snapshot picture behind the object and use it" is missing, and could be useful for effects.
Hi François,
Thanks for your comments about Inkscape filters feature. I understand your frustration about slowness. Filters remain a very young tool and their rendering could be optimized ; that's only a matter of time I think and there will be some progress with Cairo rendering (most probably in 0.49).
About non wyziwyg the main problem concern chiefly the filters containing one primitive (Convolve matrix) which at the moment remains resolution dependent.
You are not the first one to propose interesting mockups for the filters tool and your one is perhaps more interesting again because it's directly linked with the 3D rendering software world which shares some important primitives with Inkscape filters : Turbulence, Displacement, Phong shading in lightings... Perhaps did you see the following pages already :
http://wiki.inkscape.org/wiki/index.php/Filter_Effects#Mockups_of_Filter_edi...
However, some years ago I worked with 3D software like Lightwawe and C4D and despite the two programs have a GUI like yours, they also keep a tree like alternative very similar to Inkscape Filters editor. I think it's very important to give the user the choice of his tool in function of his mind ; this isn't only a matter of learning but it's also a question of personal ability. Aren't we in free software world ? Thus instead of replacing the existing tool by another one my opinion is that one should develop the kind of tool you want or you need. Inkscape community is open to all proposals and development collaboration !
On the other hand some work is done at the moment in the customizable filters area. There is a blueprint on Launchpad about that : https://blueprints.launchpad.net/inkscape/+spec/custom-predefined-filters If you compile Inkscape devel you will discover progressively more of them in the Experimental Filters submenu.
Regards,
ivan
________________________________ De : Teto <teto45@...2519...> À : inkscape-devel@lists.sourceforge.net Envoyé le : Dim 19 décembre 2010, 11h 53min 25s Objet : [Inkscape-devel] A proposal for the filter tool (and the others)
Hi!
First, I have to say that I do like inkscape, that I use everyday, sometimes just for fun. But, like all free softwares, it has few problems. Some are not important, others may become disabling. Obviously filters belong to the second category. Not because there are buggy (they aren't), but because the rendering engine is just too slow, when you are using few "big" filters in a big picture and you want to export in a big size, it takes centuries. I'm not complaining, I take a coffee during the export, but well... And it has other few problems like "what you see is not really what you get". More than this, useful features are missing: using filter in another filter, disable/mask an effect without remove it, things like that. Again, I'm not complaining, developing a soft like Inkscape is a hard stuff, and you, developers, do a great job.
First remark: When we watch filter structure closely, it's very similar to "path effects" and even "stroke" or "shape". You have an object that you change with effects: colors, shape, style and so on.
For fun, again, I use UDK (Unreal Development Kit) to develop games (mostly to understand how they work). I suppose that many people know this kit, if not, search "Epic Unreal Development Kit". In this kit, like all other game development kits, you apply materials to 3D objects, that are basically textures improved with a lot of effects to fake light, glow, deepness, relief and so on. To create these effects, you use a GUI (attached picture) where you start with the 3D object (the big rectangle on the left) and put on it effects, which can be modified by sub-effects, which can be etc. The attached picture is obvious, and shows clearly how it works, I think.
What do I want to say? I think that many tools/operations of Inkscape can be done via a GUI like this. - Everything can be a "basic" object: line, stroke, shape, geometric shape, group, clone. - On these objects you can change 4 things: shape (fill or edge) and color (fill of edge). That's all. - For the effects available you find all tools available in "filter" or "path effects", like bending, matrix operations, styles... - So when I want to put a "object on fire" effect on a circle, I click on it, a window like the attached picture is opened, I can see the object "circle" on the left, and few effect already attached, like fill color and the type of the stroke for the edge. I'm choosing the filter "on fire" in the library, and put it. I'm using dashes to tell where it's used, configuring it, closing the GUI, and the effect appears. - You see also what I mean: With this system you can create you own effects and use them like "basic effect" in other filters (missing feature in the actual filter tool). - It's the same for the objects themselves. For instance you could have a 'group' with effects (filter, transparency,...) with many sub-objects/shapes with their own effects. - Many existing GUI/tools in Inkscape could disappear with this one, and changed by "basic effect objects" attached on shapes/strokes: Tools filter, path effect, color, text, transform, tiling, distribute, 'rows and columns'...
I do know that the work for this is huge (another summer google contest?). You have to start from scratch, basically. And I read somewhere that for futures versions, Inskcape will merge "filter tool" and "path transform tool" in order to unify all this stuff. I agree, it's essential for my point of view, if you want to continue improving your great tool without too much trouble. My idea can be useless, because the concept doesn't fit with the .svg specifications (I'm thinking about colors or edge thickness, for example, that are directly in the object definition, while filters are stored in svg:defs). Or compatibility with other softs that reading .svg. Or maybe you don't care. But implement this and many expensive professional vectorial tools will become "old-school" immediately ^^ ...
Sorry for the length. And sorry if I seemed arrogant or smug, it wasn't my intention, English is not my native language. I just had this idea this morning.
My 2 cents, François.
PS: About the actual filter tool: Maybe I missed something, but the tool "snapshot picture behind the object and use it" is missing, and could be useful for effects.
However, some years ago I worked with 3D software like Lightwawe and C4D and despite the two programs have a GUI like yours, they also keep a tree like alternative very similar to Inkscape Filters editor. I think it's very important to give the user the choice of his tool in function of his mind ; this isn't only a matter of learning but it's also a question of personal ability. Aren't we in free software world ?
Forgive me if this is just flamebait, but I think multiple options for the same function is usually a bad idea. Sure, OSS is all about choice, but more often than not (without having done extensive research on the subject), one very-well-designed option that everyone stood behind would have served the community better than 2 or 3 choices that cause endless disagreements.
With two tools that achieve the same functionality (under the hood), you just have to maintain more stuff. You have to have two sets of developers. New features have to have two sets of UI elements developed to interact with them. New code has to be tested in two places. Documentation for new users becomes hard to write without making it confusing.
I believe the underlying filter framework is great, and the UI is mostly workable. I believe to bring Inkscape's filters to be as good as the potential provided by the underlying filter framework, the changes don't need to be as all-encompassing as some of the things being discussed in this thread. I think the following list would remove almost all of the barriers to using the current filter system:
- Super quick onscreen performance. While it may not be possible for them to feel *instant*, the further from instant they are, the more frustrating they are to work with, and the less likely anyone is to use them, and the less likely anyone is to experiment with creating their own awesome filters - A set of (better) predefined matrices, with user-defined variables, for color & convolve matrix effects. - Easier to change matrix values. Eg, currently editing matrixes involves a lot of "click-delay-click-edit" because of the UI widget -- you can't do it fast, because it interprets two clicks as a double-click which does nothing. - Variables with easy-to-use UI in the predefined filters (like you get when you select a predefined filter, but still available when you edit it later on). For example: if I select the drop shadow filter, I only get one chance to set the offset in terms I understand. To edit it thereafter, without deleting the filter and starting over again. I have to edit some pretty technical stuff. - Automatically turn on enable-background=new when necessary - 100% reliability.
I know some of these things are what everyone's working towards anyway (eg reliabilty & performance), and of course it's not always possible to achieve perfection here! But I just though a list might be helpful.
- Bryan
On Dec 19, 2010, at 11:58 AM, Bryan Hoyt | Brush Technology wrote:
Forgive me if this is just flamebait, but I think multiple options for the same function is usually a bad idea. Sure, OSS is all about choice, but more often than not (without having done extensive research on the subject), one very-well-designed option that everyone stood behind would have served the community better than 2 or 3 choices that cause endless disagreements.
Information keeps coming out that "one true way" just does not exist. Quantitative studies show that multiple options are actually best.
It's confusion and non-discoverability that need to be kept down. Often people try to limit confusion by limiting choice, but that is an artificial approach.
Malcom Gladwell explains it quite well in this TED talk: http://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html
This is especially applicable here where you have a bit of software used by very technically minded people for doing diagrams & illustration, artists of all sorts using it for creative purposes, software engineers using it for UML sketches and flow diagrams, etc.
Forgive me if this is just flamebait, but I think multiple options for
the same function is usually a bad idea. Sure, OSS is all about choice, but more often than not (without having done extensive research on the subject), one very-well-designed option that everyone stood behind would have served the community better than 2 or 3 choices that cause endless disagreements.
Information keeps coming out that "one true way" just does not exist. Quantitative studies show that multiple options are actually best.
It's confusion and non-discoverability that need to be kept down. Often people try to limit confusion by limiting choice, but that is an artificial approach.
Excellent point. But I think TMTOWTDI is often used as an easy excuse for not doing the hard work of solving disagreements & designing a single good solution. Often the multiple choices available don't really serve a good purpose, except that some aspects of each choice are designed better than the alternative, so neither choice solves the problem completely. If the designers of both choices were to put their best ideas together, then more often than not, you wouldn't have to provide multiple overlapping solutions.
I like the way The Zen of Python states it: "There should be one-- and preferably only one --obvious way to do it." I guess that still allows for what you're saying.
I really like Teto's proposal, and think it's a more intuitive option. It also would require a lot of development, I think, so I would rather see the smaller problems with the existing filter system fixed. Otherwise we all just have to wait another 3 years to get a filter/effects system that's pleasant to use! I feel like we've all been waiting a long time already for the current filter system to become pleasant to use (no offense to the developers -- I love it & use it anyway).
But I think if we go with Teto's proposal, when it's complete it will provide all the functionality that the current filter editor has (and much more), in a simpler, more widely-understood interface, so why would we bother maintaining a separate piece of code that offers less and is no simpler to use?
Maybe I'm just knee-jerking. I get frustrated by the GTK vs QT situation on the Linux desktop, which has watered down so much valuable OSS human resource over the years, for very little gain (ok, now there's some flamebait for everyone... email me privately if you want to shoot me down).
Malcom Gladwell explains it quite well in this TED talk:
http://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html
Very relevant, thanks. I've been reading "The Tipping Point" recently, same author -- great book, though not really applicable in this context.
On another note, it strikes me that although his main point (we need to give people choices) is relevant, the specific options are still based significantly on market research. None of the best options were chosen simply because some academic hypothesized they would be popular.
Another Zen of Python applies here: "In the face of ambiguity, refuse the temptation to guess."
- Bry
On Dec 19, 2010, at 3:07 PM, Bryan Hoyt | Brush Technology wrote:
Excellent point. But I think TMTOWTDI is often used as an easy excuse for not doing the hard work of solving disagreements & designing a single good solution. Often the multiple choices available don't really serve a good purpose, except that some aspects of each choice are designed better than the alternative, so neither choice solves the problem completely. If the designers of both choices were to put their best ideas together, then more often than not, you wouldn't have to provide multiple overlapping solutions.
I like the way The Zen of Python states it: "There should be one-- and preferably only one --obvious way to do it." I guess that still allows for what you're saying.
No, it doesn't.
That's the whole point of that TED talk. There should not be just one way to do it, and there usually is never a "one best way".
On Dec 19, 2010, at 3:07 PM, Bryan Hoyt | Brush Technology wrote:
But I think if we go with Teto's proposal, when it's complete it will provide all the functionality that the current filter editor has (and much more), in a simpler, more widely-understood interface, so why would we bother maintaining a separate piece of code that offers less and is no simpler to use?
Maybe I'm just knee-jerking. I get frustrated by the GTK vs QT situation on the Linux desktop, which has watered down so much valuable OSS human resource over the years, for very little gain (ok, now there's some flamebait for everyone... email me privately if you want to shoot me down).
Malcom Gladwell explains it quite well in this TED talk: http://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html
Very relevant, thanks. I've been reading "The Tipping Point" recently, same author -- great book, though not really applicable in this context.
On another note, it strikes me that although his main point (we need to give people choices) is relevant, the specific options are still based significantly on market research. None of the best options were chosen simply because some academic hypothesized they would be popular.
Yes... but in this context I can see a *few* ways to do it are best.
For example, some people simply *love* the blender node-based interface for combining things... and some people hate it. I believe it comes down to the fact that there is no *single* way to do that, but for some people one interface is better and for other people a *different* interface is best.
http://www.blender.org/index.php?eID=tx_cms_showpic&file=uploads%2Fpics%...
or
For *some* users that is a very good interface. For *other* users that is a really poor interface.
It's similar to giving people directions. For some people the best approach is to give them a single linear list of turn-by-turn directions (first left, second right after the third stop sign, etc). For other people the best approach is the spacial one where you give them a simple line-map. There is not a single approach that is optimal for both types of thinkers (although combining both of the two is often most useful).
No problem !
As you understood perhaps I have nothing against the structure of Filters Editor and for my use at designing filters I feel it personally very convenient. But I think room must be kept for other innovative initiatives. For a long time now I compare Vector drawing programs to 3D software because of the complexity and diversity of the tasks they must manage. I think Inkscape lacks of a true object manager inspired from 3D programs and which put together Layers, Groups, Objects, Clones, Filters and all other non destructive things and for example allows to drag and drop objects from a group or a layer to another, a filter from an object to another or to a group, or to a layer. Focusing on that is perhaps more important than anything else concerning the UI. However the 3D programs I used in the past allowed for example the use of third party rendering engines and these engines had often very different GUI.
Otherwise I second all your proposals but I personally I would also insist on :
* completing the implementation of filters (Image and Tile filters are not complete nor Convolve matrix which lacks Resolution independance) * increasing color channels up to 16 bits
* fixing bugs and inconsistencies of the Filters Editor
* adding somewhere a filter resizing / rotating / skewing utilityivan
________________________________ De : Bryan Hoyt | Brush Technology <bryan@...2310...> À : Ivan Louette <ivan_louette@...48...> Cc : Teto <teto45@...2519...>; inkscape-devel@lists.sourceforge.net Envoyé le : Dim 19 décembre 2010, 20h 58min 13s Objet : Re: [Inkscape-devel] Re : A proposal for the filter tool (and the others)
However, some years ago I worked with 3D software like Lightwawe and C4D and despite the two programs have a GUI like yours, they also keep a tree like alternative very similar to Inkscape Filters editor. I think it's very important to give the user the choice of his tool in function of his mind ; this isn't only a matter of learning but it's also a question of personal ability. Aren't we in free software world ?
Forgive me if this is just flamebait, but I think multiple options for the same function is usually a bad idea. Sure, OSS is all about choice, but more often than not (without having done extensive research on the subject), one very-well-designed option that everyone stood behind would have served the community better than 2 or 3 choices that cause endless disagreements.
With two tools that achieve the same functionality (under the hood), you just have to maintain more stuff. You have to have two sets of developers. New features have to have two sets of UI elements developed to interact with them. New code has to be tested in two places. Documentation for new users becomes hard to write without making it confusing.
I believe the underlying filter framework is great, and the UI is mostly workable. I believe to bring Inkscape's filters to be as good as the potential provided by the underlying filter framework, the changes don't need to be as all-encompassing as some of the things being discussed in this thread. I think the following list would remove almost all of the barriers to using the current filter system: * Super quick onscreen performance. While it may not be possible for them to feel *instant*, the further from instant they are, the more frustrating they are to work with, and the less likely anyone is to use them, and the less likely anyone is to experiment with creating their own awesome filters * A set of (better) predefined matrices, with user-defined variables, for color & convolve matrix effects. * Easier to change matrix values. Eg, currently editing matrixes involves a lot of "click-delay-click-edit" because of the UI widget -- you can't do it fast, because it interprets two clicks as a double-click which does nothing. * Variables with easy-to-use UI in the predefined filters (like you get when you select a predefined filter, but still available when you edit it later on). For example: if I select the drop shadow filter, I only get one chance to set the offset in terms I understand. To edit it thereafter, without deleting the filter and starting over again. I have to edit some pretty technical stuff. * Automatically turn on enable-background=new when necessary * 100% reliability. I know some of these things are what everyone's working towards anyway (eg reliabilty & performance), and of course it's not always possible to achieve perfection here! But I just though a list might be helpful.
- Bryan
On 2010-12-19 11:53, Teto wrote:
Hi!
First, I have to say that I do like inkscape, that I use everyday,sometimes just for fun. But, like all free softwares, it has few problems. Some are not important, others may become disabling. Obviously filters belong to the second category. Not because there are buggy (they aren't), but because the rendering engine is just too slow, when you are using few "big" filters in a big picture and you want to export in a big size, it takes centuries. I'm not complaining, I take a coffee during the export, but well... And it has other few problems like "what you see is not really what you get". More than this, useful features are missing: using filter in another filter, disable/mask an effect without remove it, things like that. Again, I'm not complaining, developing a soft like Inkscape is a hard stuff, and you, developers, do a great job.
If it's not WYSIWYG then there's a generally a bug (although minute variations can occur legitimately, due to rounding and such, those are rarely visible). And these do occur (Inkscape's filtering code is definitely not free of them), so don't hesitate to file a bug if you find an issue with one or more filters, or (most likely) a certain way of using them.
As for speed. Well, that's always an interesting issue :) Without sacrificing quality or using hand-written assembly or the graphics card a lot of filters are currently about as fast as they're going to get (although getting them a bit faster is still possible, and there's also some room left for improvement in "overhead"). There are also filters which are still coded in a "stupid" way and have lots of room for improvement (this includes the morphology filter). In general, if there is a specific filter you have an issue with: file a bug, and remember to also state your expectations.
... My idea can be useless, because the concept doesn't fit with the .svg specifications (I'm thinking about colors or edge thickness, for example, that are directly in the object definition, while filters are stored in svg:defs). Or compatibility with other softs that reading .svg. Or maybe you don't care. But implement this and many expensive professional vectorial tools will become "old-school" immediately ^^ ...
You're ideas are definitely not useless! They do indeed clash a bit with SVG's concepts, but hey, there is always SVG 2 :) Also, in some cases Inkscape can be made to work around SVG's limitations.
The most fundamental clash might be that SVG considers the fill and stroke of an object to be part of the same object, and cannot apply different filters to them. I'm also not sure that that makes sense (at least not within the current framework). If you're talking about stroking or filling as being a kind of "effect" that acts upon an abstract shape, then I think that could indeed make sense. Is there any application that does this? And/or can you make more detailed mockups of how you would like to see this kind of thing work in Inkscape?
Also, SVG doesn't really allow the use of making filters that can be reused in other filters (as far as I know), but this is so incredibly useful that we'll definitely figure something out (as Ivan wrote there is already some work underway).
... PS: About the actual filter tool: Maybe I missed something, but the tool "snapshot picture behind the object and use it" is missing, and could be useful for effects.
It sounds like you're looking to use BackgroundImage as source. This is supported, but does not work perfectly with all filters yet (basically it only works with filters that work per pixel, like the color matrix filter). It also has some other caveats, but that's a bit beyond the scope of this thread, if you're having trouble getting it to work, drop us a line.
2 answers:
Le 19/12/2010 17:16, Jasper van de Gronde a écrit :
The most fundamental clash might be that SVG considers the fill and stroke of an object to be part of the same object, and cannot apply different filters to them. I'm also not sure that that makes sense (at least not within the current framework). If you're talking about stroking or filling as being a kind of "effect" that acts upon an abstract shape, then I think that could indeed make sense. Is there any application that does this? And/or can you make more detailed mockups of how you would like to see this kind of thing work in Inkscape?
Also, SVG doesn't really allow the use of making filters that can be reused in other filters (as far as I know), but this is so incredibly useful that we'll definitely figure something out (as Ivan wrote there is already some work underway).
Yes I can write a mockup and what I think about, but I won't for the next couple of weeks (job, Christmas, things like that ^^ ) but since I can touch my computer again, I will. Basically, I'm thinking about a abstract shape without fill/stroke (just its shape made by the normal tools), having just a reference to a filter (in svg:defs) where you have all definitions for colors, filters and so on.
It sounds like you're looking to use BackgroundImage as source. This is supported, but does not work perfectly with all filters yet (basically it only works with filters that work per pixel, like the color matrix filter). It also has some other caveats, but that's a bit beyond the scope of this thread, if you're having trouble getting it to work, drop us a line.
Yep it's BasckgroundImage as source. As I tried it and didn't work at all, so I figured that it was for another purpose (but which one?) and stopped to use it. It just works with pixels? Pity ^^. Sorry but I don't understand: When you rendering the picture, layer by layer, object by object, from the deepest one to the closest one, it's not possible to check if the filter in the next object needs the 'rendering at this point' of the picture to have its 'backgroundImage as source'? Or maybe it's out of the .svg specifications? Example: You have a picture with 10 shapes. Object 1 the deepest, object 10 the closest. The rendering start with the object 1, draw it, next the 2nd, renders it, and so on. At the 8th, the object says: Hey! I need the rendering of the picture at this point because I do. The render answers OK, give the rendered picture, and waits until object 8 has finished its stuff. The object 8 keeps only the needed part and use it. Then it gives the result to the renderer which continues its job. The renderer doesn't work like this?
Regards, François.
On 2010-12-19 18:26, Teto wrote:
...
It sounds like you're looking to use BackgroundImage as source. This is supported, but does not work perfectly with all filters yet (basically it only works with filters that work per pixel, like the color matrix filter). It also has some other caveats, but that's a bit beyond the scope of this thread, if you're having trouble getting it to work, drop us a line.
Yep it's BasckgroundImage as source. As I tried it and didn't work at all, so I figured that it was for another purpose (but which one?) and stopped to use it. It just works with pixels? Pity ^^.
Well, sort of. Inkscape renders in tiles, and currently the background doesn't get told yet what margin it should have available in order for any filters to render properly. This means that things like blur (which need pixels outside the currently rendered area) don't work well near the edges of tiles. But anything that works per-pixel does work (color matrix, blend, composite, diffuse lighting, and some related ones).
Sorry but I don't understand: When you rendering the picture, layer by layer, object by object, from the deepest one to the closest one, it's not possible to check if the filter in the next object needs the 'rendering at this point' of the picture to have its 'backgroundImage as source'? Or maybe it's out of the .svg specifications?
It's definitely possible, and it's indeed explicitly against the SVG specifications. But, there is a reason for that. Basically the problem is that if you use BackgroundImage, you will HAVE to render the background first (which is common btw), but in order to render the right piece of the background you have to know what other objects use which parts. This can be difficult if you want to render in one go (which I think is (mostly?) possible with SVG, and was probably done to allow for very simple renderers).
There is also the matter of how far "back" the background should go. Should the background consist only of the element just above the current element, all previous elements, or some number of elements? The current SVG specification basically defaults to no elements, letting the author specify exactly where he wants the background to "start".
There has been some talk of getting this kind of thing "fixed" in a future version of SVG, but that'll take a while, and as usual there are of course conflicting interests. In the mean time we will try to get our part fixed :)
Example: You have a picture with 10 shapes. Object 1 the deepest, object 10 the closest. The rendering start with the object 1, draw it, next the 2nd, renders it, and so on. At the 8th, the object says: Hey! I need the rendering of the picture at this point because I do. The render answers OK, give the rendered picture, and waits until object 8 has finished its stuff. The object 8 keeps only the needed part and use it. Then it gives the result to the renderer which continues its job. The renderer doesn't work like this?
Nope. Suppose you have a file like this (very simplified): <svg> <rect id="a"> <g> <rect id="b"> <g> <rect id="c"> </g> <rect id="d"> </g> <rect id="e"> </svg>
It starts with object a, then progresses downwards (and thus inwards). When it comes at object c it may find that it needs the background in order to process any filters that might be applied to object c. With the current SVG specification it could be that he should get the result of rendering shapes a and b, only b or even NOTHING (the latter is the default). Note that shapes d and e are rendered after (and come on top of) shape c.
If you turn this around and start with rendering e (the topmost shape), this does not get any easier. Because then you would still have to render a and b when you get to c. In either case there is some feedback needed.
Note that there is something to be said for basically giving a group as "parameter" to a filter, but that's a different concept altogether. One I hope to see in SVG 2.
BTW, Inkscape does have a representative in the SVG WG these days, and in principle anyone can make suggestions on their mailing list, so there are some avenues for trying to influence the future of SVG, even (or perhaps especially) for less technical people.
2010/12/19 Jasper van de Gronde <th.v.d.gronde@...528...>:
As for speed. Well, that's always an interesting issue :) Without sacrificing quality or using hand-written assembly or the graphics card a lot of filters are currently about as fast as they're going to get (although getting them a bit faster is still possible, and there's also some room left for improvement in "overhead"). There are also filters which are still coded in a "stupid" way and have lots of room for improvement (this includes the morphology filter). In general, if there is a specific filter you have an issue with: file a bug, and remember to also state your expectations.
The Cairo branch includes a much better morhpology filter - it is O(N) in radius instead of O(N^2) like the old one. Other filters also have improved performance.
The big problem with filter rendering right now is not their performance, but that to render a filtered tile we need to know a lot of the background. For example, Gaussian blur needs to know not only the contents of the current tile but also things outside it. We currently do not cache anything, so we end up re-rendering the same things over and over. Performance in this case could be improved a lot through caching, but it requires some experimentation.
If you're talking about stroking or filling as being a kind of "effect" that acts upon an abstract shape, then I think that could indeed make sense. Is there any application that does this? And/or can you make more detailed mockups of how you would like to see this kind of thing work in Inkscape?
Sounds a lot like SVG 1.2 vector effects.
It sounds like you're looking to use BackgroundImage as source. This is supported, but does not work perfectly with all filters yet (basically it only works with filters that work per pixel, like the color matrix filter). It also has some other caveats, but that's a bit beyond the scope of this thread, if you're having trouble getting it to work, drop us a line.
The semantics of BackgroundImage in SVG 1.1 are do not make any sense whatsoever to me - you have to explicitly enable background accumulation, and it works differently than normal rendering. For example, opacity has no effect when rendering BackgroundImage.
Regards, Krzysztof
2010/12/19 Teto <teto45@...2519...>:
But, like all free softwares, it has few problems. Some are not important, others may become disabling. Obviously filters belong to the second category. Not because there are buggy (they aren't), but because the rendering engine is just too slow, when you are using few "big" filters in a big picture and you want to export in a big size, it takes centuries.
The Cairo branch will make this problem slightly less severe. In some workloads it is many times faster. I also want to make an OpenCL backend for Cairo, which will allow it to use modern GPUs, but this is a more long term goal. Right now we are waiting until Cairo fixes this bug, which is the last issue precluding a merge: https://bugs.freedesktop.org/show_bug.cgi?id=32215
Regards, Krzysztof
Yes, I read this (but tried to write a readable text, without too many sidetracks), and I hope it'll be in the trunk as soon as you can! :crossfingers: Many thanks anyway for trying to do something.
Merry Christmas, François.
Le 19/12/2010 17:39, Krzysztof Kosiński a écrit :
2010/12/19 Teto<teto45@...2519...>:
But, like all free softwares, it has few problems. Some are notimportant, others may become disabling. Obviously filters belong to the second category. Not because there are buggy (they aren't), but because the rendering engine is just too slow, when you are using few "big" filters in a big picture and you want to export in a big size, it takes centuries.
The Cairo branch will make this problem slightly less severe. In some workloads it is many times faster. I also want to make an OpenCL backend for Cairo, which will allow it to use modern GPUs, but this is a more long term goal. Right now we are waiting until Cairo fixes this bug, which is the last issue precluding a merge: https://bugs.freedesktop.org/show_bug.cgi?id=32215
Regards, Krzysztof
participants (6)
-
Bryan Hoyt | Brush Technology -
Ivan Louette -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński -
Teto