Proposal: get rid of bbox coords for gradients
In SVG, when an object uses a gradient fill, there are two ways to specify the points that define the gradient position (two ends of the vector for linear; center, focus, and radius for radial). First, you can use userspace coordinates which are just regular coordinates in the document space, much like any other coordinates that govern the placement of objects. And second, you can use bounding box coordinates which are relative to the bbox of the object that uses the gradient; for example, the point (0.5, 0.5) will be at the center of its bbox.
These two coordinate systems are functionally equivalent, i.e. there's no gradient that can be expressed in one system and not the other. Obviously, bbox coordinates are more convenient for those who read/write SVG manually. For an interactive editor like Inkscape, however, bbox coords are a nightmare. The reason is simple: for arbitrary transformations of arbitrary objects, you cannot predict the bbox after transformation, because it depends on the shape of the object.
A simple example: a circle and a square, with equal bboxes, are both rotated 45 deg; now their bboxes are very different. This means that if both use a gradient with bbox coordinates, the gradients will be displaced differently relative to these shapes after the transformation. With userspace coords, however, you just multiply each gradient point by the same transfomation matrix, and the object is transformed along with its gradient as a whole, without any displacement or desynchronnization.
So, when I decided to sanitize gradient handling, the first thing I did was write a function that translates a gradient from bbox coords to userspace coords. This function is now called whenever you transform an object with gradient. Without this, it would be impossible to implement the "transform with object" switch which now works reliably for any shapes or paths, in both "preserve" and "optimize" modes. This means, however, that gradients with bbox coords can only survive so long as you don't transform their users.
Now, initially my plan was to add a reverse function to convert userspace back to bbox (relative to the object's new bbox, of course) after the transformation, if initially it used bbox coords. This is the least intrusive approach, but the more I think about it the less I like it. This adds more complexity to the already quite complex system of adjustments and compensations that fires every time you transform something. And more importantly, it's just useless. Bbox coords offer no advantages whatsoever in an interactive application; they just make things more complex and potentially confusing to the user.
So, now my plan is:
- Do not convert gradients to bbox coords ever, only from bbox to userspace (as now).
- In Fill&Stroke, remove the "Coordinates" switch from the gradient pane, and make it always create gradients with userspace coords. This switch has no visible effect anyway, so it is likely to be confusing, especially for novices.
In other words, the ability to _show_ bbox coords remains, but I plan to remove the ability to _create_ them, and they won't be preserved when you transform things.
I have found only one situation where userspace/bbox makes a difference: Paste style. Consider a rect with a vertical linear gradient, black to white. Copy it and paste the style (Ctrl+Shift+V) to another rect which is below the first one. If the coords were bbox, then the new rect will also be black-to white in its place. If the coords were userspace, however, the new rect will be all white, and its black-to-white transition will be outside of its shape, in line with the old rect above it.
As for me, I do not consider this a disadvantage, because I often need exactly this behavior (i.e. I want the gradient to stay unmoved relative to the canvas so that the new objects "continue" it) and rarely if ever need the other behavior (where pasted gradient is moved to the position of the new object). Others however may have different preferences. There may also exist advantages to bbox coords that I'm missing. Hence this call for opinions; please put forward your thoughts on this. If there's no opposition, I'll proceed with the above plan.
Sorry, Bulia,
your mail was long, and I'm not 100% sure if you mentioned anything about this:
Right now with canvas coordinates when I move a object, the gradient stays where it is, showing different parts of it. I read something about rotation, where it was easy to caculate the right transformation, so I hope that this applies to moving aswell, since a gradient that doen't move is quite useless most times.
David
Right now with canvas coordinates when I move a object, the gradient stays where it is, showing different parts of it. I read something about rotation, where it was easy to caculate the right transformation, so I hope that this applies to moving aswell, since a gradient that doen't move is quite useless most times.
No. You must be speaking about 0.39. In CVS, the gradient either moves solid with the object or stays unmoved, depending on a toggle button on the selector controls bar. This works reliably for any objects now. My email discusses what is the next step after implementing this.
As a user & wanna-be dev, I'll chime in. =)
First off I'll state that I use inkscape for everything from doing design work for the law firm I work at to my personal use which is purely illustration, so I have some varying/diverse needs.
I have found only one situation where userspace/bbox makes a difference: Paste style. Consider a rect with a vertical linear gradient, black to white. Copy it and paste the style (Ctrl+Shift+V) to another rect which is below the first one. If the coords were bbox, then the new rect will also be black-to white in its place. If the coords were userspace, however, the new rect will be all white, and its black-to-white transition will be outside of its shape, in line with the old rect above it.
As for me, I do not consider this a disadvantage, because I often need exactly this behavior (i.e. I want the gradient to stay unmoved relative to the canvas so that the new objects "continue" it) and rarely if ever need the other behavior (where pasted gradient is moved to the position of the new object). Others however may have different preferences. There may also exist advantages to bbox coords that I'm missing. Hence this call for opinions; please put forward your thoughts on this. If there's no opposition, I'll proceed with the above plan.
Ok... so first off I have a Q. In the stroke & fill editor, when working with radial gradients, it has a dropdown box for "coordinates" where you can choose object or user space. Would this still work the same since all coords will be userspace? I can tell you I use both userspace and object for that option frequently. If it impacts this function, I say it would hurt too much. But, I'll assume this is unaffected as you state the pasting of styles is the only thing it should affect.
However, more times than not, I need to paste a style that will be the same as what was copied, not somewhere else further down along the "line" of the gradient. Primarily with layout/design stuff I need it to be the same. And same goes for a significant chunk of my illustration stuff... although I could definitely see it working to my advantage to have that continuation sometimes (had about 10 examples pop into my head). So if you do decide to go ahead and make that change, I think I'll file an RFE for more controls over copying/pasting object styles (if the behavior could even be modified once changed).
Hopefully that makes sense (and isn't dumb)... -Josh
PS: In case you're wondering what type of illustrations I do, one of my better (yet far from complete) examples is at http://www.deviantart.com/view/10029092/. And sorry for link to a raster image, but my personal art isn't open source. =)
Ok... so first off I have a Q. In the stroke & fill editor, when working with radial gradients, it has a dropdown box for "coordinates" where you can choose object or user space. Would this still work the same since all coords will be userspace?
Would _what_ work the same? As I wrote, the "object"/"user space" switch now has no immediate visible effect. It only has an effect on copy/paste style later, as far as I can see. So I plan to remove this switch. For now, please test creating your gradients in the userspace mode (with CVS version) and see if you can find an appreciable difference in rendering or behavior.
I can tell you I use both userspace and object for that option frequently.
What for (apart from pasting style)?
However, more times than not, I need to paste a style that will be the same as what was copied, not somewhere else further down along the "line" of the gradient.
I.e. so that the gradient is unmoved relative to the canvas? If so that's what userspace gradients will provide.
With CVS Inkscape, do this experiment:
1. Draw a rect, open fill&stroke, switch it from flat color to linear gradient. By default it is created with bbox coords.
2. DO NOT MOVE that rect, but Ctrl+C it and Ctrl+Shift+V style to some other objects around it.
3. Now move the original rect a bit (this will convert its gradient to userspace coords behind the scenes - no visible change) and copy/paste style from it again to compare.
head). So if you do decide to go ahead and make that change, I think I'll file an RFE for more controls over copying/pasting object styles (if the behavior could even be modified once changed).
It is possible to make an option (default off) to translate gradients to bbox on copy, so that they're pasted as in 2 above not as in 3. However this requires some more work (we need the clipboard to become a regular document, as we planned long ago, for this to work - we cannot make this coords conversion in the source document because copy must not change the source).
With CVS Inkscape, do this experiment:
- Draw a rect, open fill&stroke, switch it from flat color to linear
gradient. By default it is created with bbox coords.
- DO NOT MOVE that rect, but Ctrl+C it and Ctrl+Shift+V style to some
other objects around it.
- Now move the original rect a bit (this will convert its gradient to
userspace coords behind the scenes - no visible change) and copy/paste style from it again to compare.
So to make this clear:
Before the behavior was always as in 2;
Now, as you see, it's kinda broken and mid-way, depending on whether you move the object or not;
In the future I plan to make it act always as in 3 (but maybe add an optional 2 later).
Would _what_ work the same? As I wrote, the "object"/"user space" switch now has no immediate visible effect. It only has an effect on copy/paste style later, as far as I can see. So I plan to remove this switch. For now, please test creating your gradients in the userspace mode (with CVS version) and see if you can find an appreciable difference in rendering or behavior.
Sorry for not being clear... My question was, if you are working with [groups of/grouped] objects with gradient fills, would the object & userspace options (in the coordinates dropdown of the fill & stroke dialog) still behave the same? I just think we may be talking about different things that have the same name. (My example to try is further down)
A concern of mine was that it sounded like everything would be operating based on userspace, and I was worried it would muck up that coordinates option if I chose "object". Again, sorry for not being clear.
I tried your recommendation about the pasting styles and that works how I'd expect from your description. I'm using the latest build from cortijodelrio.net. So... not as up-to-date as CVS, and CVS may be a bit different. In the version I have what I'm talking about still works fine.
I can tell you I use both userspace and object for that option frequently.
What for (apart from pasting style)?
As above, working with grouped objects in the fill & stroke dialog (with that coordinates option).
Try this to achieve what I'm talking about so you can tell me if it will affect it.
1) Create multiple objects (like 6 or so), then select them all and group them.
2) Open fill & stroke dialog and choose either type of gradient for the fill. And in the coordinates dropdown, switch between userspace and object.
That's all I'm worried about... potentially changing that specific functionality by not using the bboxes. My concern is really because the description it gives in the fill dialog (via tooltip when you hover over the "object" option for coords), it mentions using the objects bounding box to perform that action.
I really hope that makes sense.
-Josh
Ok, I have thought about this again, and I like the idea of getting rid of the bbox fill... but Josh is right, when you have a multiple objects selected and you don't want them to have one gradient, but a gradient each (just assume you want to draw many spheres -- different size maybe -- and you want to give them all a "3d" kinda radial gradient) what you'd have to do if we get rid of bbox is do the gradients one by one. (or am I mistaken here?) Now while I never liked bbox fills for librsvg screws them up most of the time (I know, not an inkscape problem) I see that they are useful for this. There should be something to toggle between "fill objects as one" and "fill each object seperate" if you have multiple objects selected. I'm not sure how this will work internally (have canvas fills afterall) but for the UI (considering the desired effect) I guess that's more understandable than than object and user_space.
David
PS: this was not actually the thread I was looking for right now :)
Ok, I have thought about this again, and I like the idea of getting rid of the bbox fill... but Josh is right, when you have a multiple objects selected and you don't want them to have one gradient, but a gradient each (just assume you want to draw many spheres -- different size maybe -- and you want to give them all a "3d" kinda radial gradient) what you'd have to do if we get rid of bbox is do the gradients one by one.
No. When you _switch_ several objects to gradients, each gets its own gradient relative to its own bbox (and using that object's color). The only difference is that these gradients are written to SVG using gradientUnits="userSpaceOnUse" instead of gradientUnits="objectBoundingBox" as before.
On Wed, 2004-10-13 at 16:00, bulia byak wrote:
So, now my plan is:
- Do not convert gradients to bbox coords ever, only from bbox to
userspace (as now).
- In Fill&Stroke, remove the "Coordinates" switch from the gradient
pane, and make it always create gradients with userspace coords. This switch has no visible effect anyway, so it is likely to be confusing, especially for novices.
In other words, the ability to _show_ bbox coords remains, but I plan to remove the ability to _create_ them, and they won't be preserved when you transform things.
Having considered it for a while, it seems sensible to me. I don't forsee much impact, and it should make things a little saner.
-mental
participants (5)
-
unknown＠example.com -
bulia byak -
David Christian Berg -
Joshua A. Andler -
MenTaLguY