Examples of work - re request to post tuts and pics

[Lazur]

Biggest issue with the filter editor: no feedback.

There is no preview on what the result should was supposed to look like when filtered.

In addition by simply copy/pasting a filtered object a new filter definition is created each time. Making the list of filters unorganised because you cannot give hints or comments or organise them into folders etc.
Nor there is an indication on any transformation affecting the rendered result.
Scaling can make a great diference between the same filter chain. At least with a preview object we can have a sense on what look were you after.


Which concludes filters may be better organised by attaching them to objects. However if you wanted to make something realistic
-for example 1.distort the shape 2. add dithering to the original fill 3. generate a texture and overlay blend it 4. generate another texture (or more) just for a bit more variance and natural look 5. add a generated shading 6. make the diffuse shader appear decent after some colour corrections and whatnot 7. generate dropshadows, maybe?-
thenyou'd better organise those separate filters either into a looong chain or your only choice is applying one filter, grouping the object filtering the group, rinse and repeat... 

Or just head over to blender and get a load of 2.8's brand new eevee (game engine) renderer.
"Principled BSDF" shader all the way.

[Moini]

What do you mean by 'there's no preview', Lazur? If you have an object selected and the check mark for the currently edited filter is set, it's immediately adjusted.

[Lazur]

I mean, if it's not applied to an object.

Even if it is applied, checking "subchains" requires a merge filter primitive and constant rigging.

Looking at a zoomed in portion is hardly possible to do in addition.

[fluxrider]

Moini, that makes sense...and the accidental deletion is a good point too.  I went ahead and took your advice (in a hybrid sort of way) and added a definitions layer that displays all of the filter variations at once, each on a single object rather than the set of eight triangles for each.
It only increased the file size by about a quarter, from 321 KB to 390.  However, once I did that, I tried the File Cleanup, and it didn't reduce the filesize by even a KB.  So I guess once the filters were in use, there were not many unused definitions at all.   ...which made me sort of obscurely happy in some way.   
I also got rid of the diamond/square bits in the filter names.  It seemed like an unnecessary complication, and I want the filters to feel accessible, not daunting.

[fluxrider]

And Lazur, I'm not sure I'm following what you're saying.  This SVG is intended as a demo of the filter variations, with the idea of applying different ones to the same object (well, the same set of eight objects) to see them.  The drawing itself is the preview window.
Personally, I really enjoy going from one variation to another and watching as it processes the new filter; what changes and what stays the same is really interesting to me.

[fluxrider]

I also added some instructions to the Gradient Guide tool, in case anyone wants to make their own alphamaps in that SVG.  The tool basically just aids in shaping and positioning your new alphamap gradient to be doing exactly what you intended it to be doing in the composite shape.
If anyone is interested in that, anyway...I find it very useful, so I thought I would include it in the SVG.

[fluxrider]

And just in case the main instructions for the SVG got lost in all my other verbiage...here they are without other distractions:

Open the SVG, and pull up your Objects dialog and Filter Editor.
In the Objects dialog, expand the “group_BigDiamond", and shift-select all eight triangles.
Then simply go through the Filter Editor and put a check in any filter to see what it looks like.

and...

To see what the change from baseline was, check the first part of the filter name, it will tell you where to look.
"Comp3" means the third Composite, Disp1 means the first Displacement Map, and so on.
Also, if the filter name starts with “Move”, that indicates the filter was changed by moving one or both of the base gradients.  To see where those gradients were moved, check the first Image primitives for that filter variation, they will show the image or SVG element they use (which will be a gradient object, similar to the original, but moved)

[fluxrider]

Lazur,
"Even if it is applied, checking "subchains" requires a merge filter primitive and constant rigging."

   I think what you are talking about here is adding a Merge, and then attaching the input to whichever earlier primitive, to see what it looks like at that point; basically a forensics method.  That sounds cool, I'll have to check that out...although I can see already that some places in the filter chain will not look very coherent, since perhaps a constraining clip or something hasn't been applied yet at that point in the filter. You would have to pick the right places to see the actual progress; the primitives that are at the "end" of some subchain.

"Looking at a zoomed in portion is hardly possible to do in addition."

   If you mean that as you zoom in, the filter takes longer and longer to process, I see that as well.  Each time I zoom in an additional level, the filter seems to take about twice as long to process.  This gets pretty long in just a few zooms.
I do notice that the size of the drawing window also affects this.  So if you're interested in looking close up at a small portion of a filtered design, you can make your drawing window small, and then you'll be able to zoom in pretty heavily on that small part, the processing time won't be as bad.
I'm also wondering whether that delay in processing would be better if the SVG didn't have all the other variations of filter in the file.  (I.e. if you only have the one filter in your SVG, does that filter take as long to process when zoomed in?) 

[fluxrider]

I made a copy and stripped out all but two of the variations, but that didn't seem to improve processing time much at all. 

[fluxrider]

...But I still really like this SVG.    
In terms of a "thumbnail view", if you zoom out to where the composite diamond shape is only two or three inches across, the processing time is almost nil.  Of course, some of the detail is lost, but that's the nature of thumbnail views...

(I have a bad habit of drowning my words in more words, so I'll try to stop now.)

[brynn]

Not speaking for Lazur, but I know he's been busy lately. 

When he's mentioned this in the past, my understanding was that he wanted a preview for each filter in the menu.  Like for example, select your object, open the menu, and you can see a preview for what the object will look like with each filter applied to it.  Of course this would need a redesign of the menu, I guess, because that would take more space than the menu currently has.

One thing that takes a lot of time with filters currently, is that you actually do have to apply every filter (or at least a lot of filters) to the object, one at a time, with Undo in between, to sample them all.  So a preview would be worth gold, for filters users.

Although it's possible I misunderstood?

[fluxrider]

If I understand you correctly, you're talking about the Filters menu in the menu bar, not the Filter Editor?  That would be nice. 
I havenot used that menu much, and probably exactly because it seems somewhat inaccessible that way.

[fluxrider]

In terms of space in the menu, a preview wouldn't necessarily have to use that space, it could just be a popup to the side when you mouse over a specific filter. (So you don't see all the previews immediately, but can see any specific preview easily by just going to that part of the menu.)

Or it could operate in the manner of some "Live Preview" options in Inkscape, where the preview happens in the drawing itself, when you mouse over that filter in the menu.  Although it seems like that might require a faster response than is feasible, people can mouse over different filters pretty quickly....

[brynn]

Yeah, I suppose those things could work.  Inkscape developers tend not to participate in forums, so except for other users chiming in, it won't generate a productive discussion.  But if I notice developers are having a discussion in the places where they generally discuss things (mailing list, gitlab, maybe in the chat, although I don't peruse the chat) I'll try to remember to let you know.