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.