RENDERING: Errors with missing vertices and fill areas

[Troy James Sobotka]

Summary: In complicated images, some rendering issues are encountered. This applies to strange realtime rendering bugs and to final output PNG renders. The bugs manifest themselves in strange ways but can be loosely summarized as strange areas being filled where they should not be.

Platform: Ubuntu Linux 7.10 amd64.

Version: 45+devel December 29th, 2007.

Frequency: Depending on complexity. With complexity in image, occurs 5/5 times trial for appearance.

Reproduction: Create a complicated image and use stroke filling. Rendering issues will result.

Samples attached. Note the large strange filled region on the middle right. Compare with source.

[Tom Davidson (tjd-mit)]

First of all--cool artwork!

-Is vertov00.png the correctly rendered 'source' image, or a png that displays the rendering bug?
-If the former, can you attach a screenshot of the buggy rendering so that we can be sure we're all talking about the same issue?

On my machine (fedora 6, running inkscape from SVN 16895 12/31/07) the rendering errors I see seem to be dependent on the zoom, which makes me think this bug could be the same issue as in bug 168437 ?

[Troy James Sobotka (troy-sobotka)]

1) vertov00.png represents a single render at page size of the source that displays the rendering bug. As you can see from the source, (or not depending on if the bug shows up ;) ) the image is perfectly symmetrical.

2) It certainly changes based on zoom level, but I have no idea why that would affect PNG output?

3) Sometimes moving other objects overtop of the error will cause the error to flip back and forth from proper rendering to incorrect.

Hope this helps.

[Tom Davidson (tjd-mit)]

Ah, OK, I didn't see the rendering glitch it the first time... Yes, that is the same type of error I see when I open your file on my setup.

[Troy James Sobotka (troy-sobotka)]

There are still instances of this bug appearing at some display zoom levels as of bzr revision 9012.

[Troy James Sobotka (troy-sobotka)]

Is there _any_ progress on these rendering bugs?

It is impossible to generate a PNG from certain work. I have tried all zoom levels now and nothing works.

Frustrating.

[su_v (suv-lp)]

> It is impossible to generate a PNG from certain work

Did you try to slightly vary the DPI when exporting to PNG (see attached PNG exported with 89 dpi, exported with r10188 on OS X 10.5.8 (i386)).

These types of rendering errors will most likely be addressed when Inkscape switches to cairo as internal renderer, which is work in progress:

1) GSoC 2010 (to be merged into trunk soon):
<https://code.launchpad.net/~inkscape.dev/inkscape/cairo-rendering>
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36305>
2) will be continued (if accepted) as GSoC 2011 project:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36211>

[su_v (suv-lp)]

By the way - quickly testing your SVG file in a local build of the cairo-renderer branch and comparing the on-canvas rendering to current trunk (same window size, same zoom levels), I don't see the same zoom-dependent artefacts (randomly incorrect filled areas) with the cairo-renderer version.

More in-depth testing of all reports about rendering glitches (zoom-dependent on-canvas and when exporting to bitmap, which also uses the same internal renderer) will certainly be done once the branch has been merged into trunk.

Attached PNG was exported with the default 90dpi using a test build from the cairo-renderer branch.

[ScislaC (scislac)]

Cannot reproduce with Inkscape trunk (still reproduced with 0.48.x). Closing this report, if you feel this was closed in error, please re-open the report and explain why.

[Troy James Sobotka (troy-sobotka)]

I must admit I find this voracious want to close bug reports absolutely shameful. I am probably delusional, but with a little research I have seen more fix committeds or wishlist flags in Inkscape than any other project.

The fact is that this colossal bug has been in Inkscape for three years.

As of two weeks ago, it was still there and worse in that I was unable to get any view of the work to render properly.

TL; DR - Inkscape doesn't render properly.

Fix committed. I don't know what to say.

[ScislaC (scislac)]

Troy, the renderer was REPLACED just a couple days ago. With r10341 I can not reproduce... I can still reproduce with what will be 0.48.2. Please reassess your attitude.

[Troy James Sobotka (troy-sobotka)]

Apologies ScislaC. I had very little to infer that the rendering system was replaced.

I will do my best to test trunk. Is there anything special to flag to get the new rendering code?

[ScislaC (scislac)]

Troy, do you compile Inkscape yourself? If not, what distro/version do you currently use? Please know that there are known issues with the new renderer which are fixed in the next version of cairo to be released (all gradient related), so all should be good by the time Ubuntu 11.10 rolls out (which the next release of Inkscape will not make, but we have a PPA so it will be available that way with 11.10s "good" cairo).

[Troy James Sobotka (troy-sobotka)]

Some bad news.

I am attaching a screenshot and an SVG using URW Gothic. It appears there are some similar issues using trunk.

Revision 10574

[su_v (suv-lp)]

Troy James Sobotka wrote:
> It appears there are some similar issues using trunk.

Most likely the same as or related to this recently reported regression:
Bug #826872 in Inkscape: “Rendering artefacts during zooming”
<https://bugs.launchpad.net/inkscape/+bug/826872>