Bezier Ellipse Shape Issue (rev >= 12921)

Bug #1544680 reported by Shabahanx on 2016-02-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Alvin Penner
0.92.x
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.

Related branches

Shabahanx (shabahanx) wrote :
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
Shabahanx (shabahanx) 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.

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) on 2016-02-11
summary: - Bezier Ellipse Shape Issue
+ Bezier Ellipse Shape Issue (rev >= 12921)
Shabahanx (shabahanx) wrote :

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

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...

Shabahanx (shabahanx) 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

Shabahanx (shabahanx) 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?

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.

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?

Shabahanx (shabahanx) 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.

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.

Shabahanx (shabahanx) wrote :

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

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)?

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.

Shabahanx (shabahanx) 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.

Shabahanx (shabahanx) wrote :

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

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.

Shabahanx (shabahanx) 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.

Alvin Penner (apenner) wrote :

could you attach the original svg file?

Shabahanx (shabahanx) 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.

Alvin Penner (apenner) wrote :

thanks, I'll check it out

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.

Shabahanx (shabahanx) 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.

Alvin Penner (apenner) wrote :

good to hear.
committed to rev 15601

Alvin Penner (apenner) wrote :
Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → Alvin Penner (apenner)
jazzynico (jazzynico) on 2017-03-19
Changed in inkscape:
milestone: 0.92 → 0.93
tags: added: backport-proposed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers