Here are some considerations about the convolve matrix ui current implementation:
(1) I think that the rows and cols parameters dont need a scroll bar since they are integer values selectable within a very small range. The scroll bar is only wasting space there since its even easiear to select the desired value directly typing it or by using the up or dow arrows.
(2) I have drawn a spline and have imported a bitmap. I have applied the same filter to both (convolve matrix) when I change the divisor or the bias parameters, the effect on the spline updates automaticaly while I scroll the bar, but on the image I MUST double click on the filter name to have the effect aplied. It is a weird behaviour I think. Do you know why is it happenning?
(3) the bias and divisor scroll bars bypass the default value behaviour (which could be desired in some ocasions, mainly because the default value seems to be usually a good choice aesteticaly) Maybe a good soulition woul be to initialize it with the default value, not zero. Also it limits the range of possible values.
(4) how do we set the targetX and targetY? Maybe we could have a little black dot indicating it on the matrix
And one desired feature for the filters ui in general: (5) it would be nice if we coul drag and drop a filter from the left list into the filter diagram area at the right in order to use it as if it was a filter primitive. In the UI it would show the filter name (it's an abstraction to the user) but behind the scenes it would probably be a copy of the filter structure connected to the rest of the real primitives implementing a "higher level" filter. You understand what I mean?
best wishes, Juca
(1) I think that the rows and cols parameters dont need a scroll bar since they are integer values selectable within a very small range. The scroll bar is only wasting space there since its even easiear to select the desired value directly typing it or by using the up or dow arrows.
Agreed, I've now changed this in svn.
(2) I have drawn a spline and have imported a bitmap. I have applied the same filter to both (convolve matrix) when I change the divisor or the bias parameters, the effect on the spline updates automaticaly while I scroll the bar, but on the image I MUST double click on the filter name to have the effect aplied. It is a weird behaviour I think. Do you know why is it happenning?
I've noticed update problems with images as well, but I'm not sure what's going on. I'll investigate further.
(3) the bias and divisor scroll bars bypass the default value behaviour (which could be desired in some ocasions, mainly because the default value seems to be usually a good choice aesteticaly) Maybe a good soulition woul be to initialize it with the default value, not zero. Also it limits the range of possible values.
The default value behavior is fixable. The limited range of values is another problem, however, where I need feedback. As I noted in the filter source code, almost all of the slider/spinbutton ranges in the code are complete guesses, since many of the filter attributes in the spec don't give much indication of desirable ranges.
(4) how do we set the targetX and targetY? Maybe we could have a little black dot indicating it on the matrix
I would suggest simply having two spinboxes to control targetX/Y, and perhaps use a different background color for the target cell in the matrix to better indicate the selection.
And one desired feature for the filters ui in general: (5) it would be nice if we coul drag and drop a filter from the left list into the filter diagram area at the right in order to use it as if it was a filter primitive. In the UI it would show the filter name (it's an abstraction to the user) but behind the scenes it would probably be a copy of the filter structure connected to the rest of the real primitives implementing a "higher level" filter. You understand what I mean?
Certainly an interesting suggestion, but this probably falls in to the "if I have time" category.
-Nicholas
On Fri, 2007-07-27 at 17:57 -0400, Nicholas Bishop wrote:
In the UI it would show the filter name (it's an abstraction to the user) but behind the scenes it would probably be a copy of the filter structure connected to the rest of the real primitives implementing a "higher level" filter. You understand what I mean?
Certainly an interesting suggestion, but this probably falls in to the "if I have time" category.
I think what we'd really want for this would be an 'feFilter' primitive which allowed one to xlink:href another filter. That would also allow us to have per-object filters much the same way we have per-object gradients.
-mental
On Monday, July 30, 2007, 5:23:33 AM, MenTaLguY wrote:
M> On Fri, 2007-07-27 at 17:57 -0400, Nicholas Bishop wrote:
In the UI it would show the filter name (it's an abstraction to the user) but behind the scenes it would probably be a copy of the filter structure connected to the rest of the real primitives implementing a "higher level" filter. You understand what I mean?
Certainly an interesting suggestion, but this probably falls in to the "if I have time" category.
M> I think what we'd really want for this would be an 'feFilter' primitive M> which allowed one to xlink:href another filter. That would also allow M> us to have per-object filters much the same way we have per-object M> gradients.
Both filters and gradients allow this sort of chaining (to arbitrary depth). Its supposed to promote re-use, with one filter or gradient being slightly modified (subclassed, kinda) for multiple objects.
In practice objectBoundingBox get you most of what's needed there and in 1.2 the filter region extensions also help with really reusable as opposed to subclassable filters: http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#filter-margins
SVG 1.2 filters module in fact deprecates using xlink href (on the grounds of increased implementor complexity for little practical gain); if you have views either for or against such deprecation it would be useful to hear them. http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#FilterElementHrefAttribut...
On Mon, 2007-07-30 at 20:07 +0200, Chris Lilley wrote:
Both filters and gradients allow this sort of chaining (to arbitrary depth). Its supposed to promote re-use, with one filter or gradient being slightly modified (subclassed, kinda) for multiple objects.
Yeah -- we take advantage of that heavily for gradients; I had missed it for filters in my reading of the spec. Good to see that something along those lines is in fact there.
In practice objectBoundingBox get you most of what's needed there and in 1.2 the filter region extensions also help with really reusable as opposed to subclassable filters: http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#filter-margins
SVG 1.2 filters module in fact deprecates using xlink href (on the grounds of increased implementor complexity for little practical gain); if you have views either for or against such deprecation it would be useful to hear them. http://www.w3.org/TR/2007/WD-SVGFilter12-20070501/#FilterElementHrefAttribut...
Niko, Nicholas, do you have any thoughts on this?
-mental
On 7/30/07, MenTaLguY <mental@...3...> wrote:
SVG 1.2 filters module in fact deprecates using xlink href (on the grounds of increased implementor complexity for little practical gain);
Hmm, so maybe we can already take advantage of that by not supporting hrefs on filters? How common are hreffed filters in the wild? I guess not very.
Mon, 30 Jul 2007 18:32:53 -0400 MenTaLguY <mental@...3...> kirjoitti:
Both filters and gradients allow this sort of chaining (to arbitrary depth). Its supposed to promote re-use, with one filter or gradient being slightly modified (subclassed, kinda) for multiple objects.
Yeah -- we take advantage of that heavily for gradients; I had missed it for filters in my reading of the spec. Good to see that something along those lines is in fact there.
Unlike with gradients, there aren't too many situations, where hrefing filters is useful. All it can do, is changing the filter effects region and rendering resolution, or inheriting them from other filter.
If it allowed modifying the actual filter primitives, there would be many other uses, but it would be a lot more complex to implement too.
On Tue, 2007-07-31 at 09:49 +0300, Niko Kiirala wrote:
Unlike with gradients, there aren't too many situations, where hrefing filters is useful. All it can do, is changing the filter effects region and rendering resolution, or inheriting them from other filter.
The main thing is that I'm thinking the filter effects region may need to be set on a per-object basis, like gradient transformations are. Perhaps not... but I know we did some dynamic stuff with that to make blur work "right" originally.
-mental
participants (6)
-
bulia byak -
Chris Lilley -
Felipe Sanches -
MenTaLguY -
Nicholas Bishop -
Niko Kiirala