Bezier Ellipse Shape Issue (rev >= 12921)

Bug #1544680 reported by Hamed Khakbiz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Alvin Penner
0.92.x
Triaged
Medium
Unassigned

Bug Description

Hello

I want to report a serious problem with Bezier Ellipse shape. For example when I draw a line with two nodes and drag two handles in the same way (like mirror) the tip of one of them will turn into the other way. I post two screenshots of the same file so you'll see what exactly I'm talking about.

Thank you.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :
Revision history for this message
su_v (suv-lp) wrote :

Please add information about OS/platform and Inkscape version to the bug description, thank you.

To allow further investigation of the reported issue, please attach a (preferably reduced) test case (Inkscape SVG file) to the bug report.

Changed in inkscape:
status: New → Incomplete
Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

I'm sorry, I'm running Fedora 23 x86_64 on AMD 7850K, AMD 285 Tonga graphic card and I'm using the opensource driver. But I also try other distributions like OpenSUSE, Deepin Linux and on Deepin I installed the fglrx but it make no differences.

Revision history for this message
su_v (suv-lp) wrote :

Reproduced with Inkscape 0.91 r13725 and 0.91+devel r14647 on OS X 10.7.5.

Based on tests with archived builds:
- not reproduced with rev <= 12920,
- reproduced with rev >= 12921;
the changed rendering of the path effect in Inkscape 0.91 compared to Inkscape 0.48.5 seems related to the 2geom update in r12921:
Revision 12921: update 2geom's copy to r2142
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12921

A few other regressions exposed with the 2geom update in rev 12921 are already fixed - some of them in 0.91: bug #1272119, bug #1312333; some in trunk/0.91.x: bug #1428683, bug #1428267.

Later changes between rev 14159 and 14165 apparently cause the affected end of the path to be rendered even thinner - probably in rev 14161 "sbasis-to-bezier. avoid ill-conditioned behavior for anti-symmetric case" (for bug 1428267):
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14161

Changed in inkscape:
importance: Undecided → Medium
milestone: none → 0.92
status: Incomplete → Confirmed
tags: added: 2geom livepatheffects regression
su_v (suv-lp)
summary: - Bezier Ellipse Shape Issue
+ Bezier Ellipse Shape Issue (rev >= 12921)
Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

So is there chance to fix this any time soon? anyway thanks for checking on this.

Revision history for this message
jazzynico (jazzynico) wrote :

Could you please test with the new Inkscape 0.92 version?
To be honest, I'm can't find out what's wrong in the SVG file from comment #3. Comparing with 0.48.5 and 0.91 doesn't show anything obvious to me. I must be blind...

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

Hi, nope the bug is still there :(
Test in both Inkscape 0.92-3.pre2 and 0.92.1-1 on Fedora 25 Workstation (Gnome) x86-64

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

This bus is set to fixed for version 0.92, but after one year and releasing the version 0.92.1 the bug still exist, how could this happened?

Revision history for this message
jazzynico (jazzynico) wrote :

> This bus is set to fixed for version 0.92

Not exactly. We hoped it could be fixed for 0.92, but unfortunately nobody found a solution (or time) to fix it. Milestone should be changed shortly.

Revision history for this message
Alvin Penner (apenner) wrote :

Hi,
   I am attempting to reproduce the bug but so far have not succeeded. I am on Windows 10, Inkscape 0.92.1 r15371 (32 bit, 7z file). Attached is the object I am editing. It appears to be responding normally when I drag the control handles.

I do not understand the instructions:
>> drag two handles in the same way (like mirror) the tip of one of them will turn into the other way

how is this done?

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

@jazzynico (jazzynico). I know it must be hard to reach a milestone and release a new version. I really hope this bug will fixed for the next milestone. Anyway thank you for checking on this.

@Alvin Penner (apenner). Check the last screenshot I've post (message #7), is this not clear? unselect the Bezier and zoom on the tip then check the angle.

Revision history for this message
Alvin Penner (apenner) wrote :

attached is a proposed patch for this bug.
Ultimately this will need to be applied to lib2geom, but I thought I would first post it here for testing purposes.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

Thanks Alvin Penner, you're awesome. I'll test this asap.

Revision history for this message
su_v (suv-lp) wrote :

Patch tested successfully with lp:inkscape/0.92.x r15400 and a reduced version of the file from comment 3. Any ideas about possibly unintended side-effects to watch out for (in PaP and other LPEs)?

Revision history for this message
Alvin Penner (apenner) wrote :

this code was originally committed to lib2geom in August 15, 2013:
https://github.com/inkscape/lib2geom/commit/e92c13f500f106d520e91be2acd1a284a3184787
and to Inkscape in rev 12921:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12921#src/2geom/sbasis-to-bezier.cpp
the original motivation for the change was to improve the rendering of ellipses, since there were a number of bug reports related to the quality of the elliptical arcs. The code will work well for cases where the Bezier arm lengths are roughly similar in size. But it does not do a good job if the arm lengths are highly dissimilar. In the current example, the Bezier curve that is causing the problem has one arm that is about 20 times longer than the other, with the result that the short arm sometimes varies quite wildly in response to a small change in the large arm. I think this will always be a problem if one is using live path effects where the two endpoints of the curve are highly dissimilar. What the patch does is to reject the higher order fit method and revert back to the original zeroth order fit method in this case.
    The current fit method uses the midpoint of the SBasis curve to try to improve the fit, relative to the zeroth order estimate. There are other fit methods that could be used instead. For example, one could fit the curvature at the endpoints, or one could fit the center of mass. I have experimented with both of these methods for curves that are quite well-behaved:
https://github.com/alvinpenner/Spiro2SVG
but I have never attempted to apply them to a situation that is as volatile as a live path effect, so I am not sure if either of them would be consistently better than the current method. It might be an interesting research project for someone to tackle.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

I tested too, I also enable the GTK3. It's much better, I don't know if it's totally fixed or not. Please check this screenshot, the tip of the bezier can be more smooth? and again thanks for working on this.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

I also try with default GTK2, the result is same.

Revision history for this message
Alvin Penner (apenner) wrote :

    thanks for the screenshots. The origin of this problem is in lib2geom, so there is no reason to suspect that the switch from gtk2 to gtk3 will have any effect on the issue. I am not very clear on exactly what the deficiency is in these two screenshots, so I don't think it will be possible to address this particular issue.
    It is true that there will potentially be some problems with the existing code. The problems will show up when you evaluate the response of the Bezier to a smooth change in an input variable. In other words, the rate of change of the output with respect to a smooth rate of change of input may not always be continuous. But I have not yet seen clear examples of such problems.
    If they do occur, then there are two possible ways of dealing with it. One way is to create yet another clamp, or patch, in order to filter out unwanted behavior. The second way is to re-evaluate the basic formulation of how the curve fit is being done in the first place. I think we are very close to the point where the second approach is becoming more attractive than the first.
    In any event I don't think there is enough info here to justify yet another patch attempt.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

The fact is I finished this work year ago and for some reasons like I use RAID-0 with two disks and once I forgot to mount it manually and because openSUSE (German distor) mount the first disk as normal disk and format the whole thing which is f****** suck I lost everything, the point is I start in version 0.48 and I finished in the same version I don't encounter any problem like this. Please check this new screenshot, I really hope I can deliver my intention.

Revision history for this message
Alvin Penner (apenner) wrote :

could you attach the original svg file?

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

Sorry I'm totally forgot to post the SVG, I don't save it but it doesn't matter because the result will be the same. I post a new file, this time the left side has issue. Remember that you must zoom in to 25600% to see the issue. I upload two screenshot plus the SVG in one Zip file.

Revision history for this message
Alvin Penner (apenner) wrote :

thanks, I'll check it out

Revision history for this message
Alvin Penner (apenner) wrote :

attached is an (improved) proposed patch for this bug.
This incorporates the changes in the previous proposed patch, plus it adds a new filter to remove highly asymmetric responses.
I thought I would post it here for testing purposes.

Revision history for this message
Hamed Khakbiz (dominusprogs) wrote :

I've tried the last patch (0.92.1 r15371) and I'm sure it's totally fixed. Thank you very much Alvin Penner.

Revision history for this message
Alvin Penner (apenner) wrote :

good to hear.
committed to rev 15601

Revision history for this message
Alvin Penner (apenner) wrote :
Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → Alvin Penner (apenner)
jazzynico (jazzynico)
Changed in inkscape:
milestone: 0.92 → 0.93
tags: added: backport-proposed
Max Gaukler (mgmax)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.