GNOME Bugzilla – Bug 321457
Improve stroke accuracy (particularly around curves)
Last modified: 2008-01-15 14:04:58 UTC
Please describe the problem: Using the stroke tool, stroking a path or selection results in inconsistent widths of the stroke. Particularly when the stroke involves a pass around curves, you may specify that the stroke is only 2 pixels wide and you may get a result that is 1 pixel wide around most of the selection and 2 pixels wide around the curves. Steps to reproduce: 1. Take a screenshot or other picture with curves 2. Use Alpha-to-Selection 3. Stroke the selection and pay particular attention to the curves in the selection Actual results: Everything performs normally except for the varying depth around curves Expected results: A consistent stroke of specified width Does this happen every time? Yes Other information:
Please leave it up to the developers to set the milestone on a particular bug report.
I don't understand this bug report in all details. I tend to believe that it is a duplicate of bug #50730. This report is rather confusing, mainly because it is old and some of the older comments are correct any longer. Perhaps we should open a new bug report to summarize the problems with stroking a selection, compared to stroking a path. It might make sense to change "Stroke Selection" to actually create a path from the selection and stroke that instead of stroking the selection boundary.
I don't know that I'd call this a duplicate of bug #50730. This bug is far more focused on the poor quality of a stroked selection. If I were to highlight or emphasize any one thing from bug #50730, it would be the "stairy" effect that occurs around edges/curves in a selection. In testing the stroke selection vs. the stroke path tool, I'd agree that the best solution would be to have it create a path and stroke the path instead of the selection boundary. The comments in bug #50730 make it seem like fixing the selection stroke tool would take more effort than it's worth and since the code to generate the desired effect is already present, it makes sense that we should do that. That leaves the option to stroke a selection present in the interface so that users aren't having to do extra work to stroke a selection by turning it into a path first, but it also generates a more satisfactory result than at present.
The stairy effect that occurs around edges/curves in a selection is what bug #50730 is all about. I am tempted to close bug #50730 and to keep this one open instead. But then this report doesn't a reproducible description. The one that you gave doesn't make much sense because a screenshot is not going to have an alpha channel, thus "Alpha to Selection" doesn't have any effect. It would probably be best to close this report as INVALID and to open a new one that is supposed to replace bug #50730.
Ahh.. I guess I neglected to mention that I'm using a theme with rounded corners on the windows and the trash content around the corners has been removed so there is indeed an alpha channel. Even if you want to remove the alpha-to-selection step and just indicate that you select a rounded area and stroke that selection, it effectively results in the same thing.
A well-done bug report would include a saved selection as a test case. However, stroking a rounded selection, I can definitely not reproduce the described behaviour. If the stroke width is set to 2 pixels, the stroke is admittedly of pour quality (for the reasons outlined in bug #50730), but it doesn't become any thinner than 2 pixels. Setting this bug report to NEEDINFO for now. I do suggest however that it is being closed as a duplicate or as INVALID and that a new bug report is opened that is qualified to replace bug #50730.
Closing as a duplicate on the basis of comments and the fact that it has been NEEDINFO for 9 months. *** This bug has been marked as a duplicate of 50730 ***