exactly adjacent rectangles, graphics glitch

[David Mathog]

There is a graphics glitch which affects flat sided objects which are exactly adjacent. For instance, the attached example is a small set of color bars from a gradient conversion. Look in the XML editor and one rectangle might extend from 200.45001 to 200.45001 + 2.45, with the next starting at 202.90001. That is, the right and left sides of the rectangle are at the same X value. Nevertheless, when displayed in inkscape the junction is not one color or the other, but something lighter than either. This occurs on both the Windows and Linux versions.

I tried editing the first value, which started at 200.45001 incrementing it slightly. Even though the two rectangles then overlapped the faint line between them did not go away until the value reached 200.46 (200.452 still had it). Looks to me like it may be a single precision float problem somewhere, possibly in Cairo.

Additionally, on linux with a similar set of color bars there were occasions where the entire fill of a bar would be shown as white, even though clicking on it and looking at the fill value in the stroke/fill window showed the expected gradient value.
I will attach an example that does that next. I could not trigger this problem on Windows.

r11598 on both platforms.

[David Mathog (mathog)]

Screen shot of the linux specific glitch. One of the bars erroneously displayed in white has been selected, notice the fill color shown is NOT white.

[su_v (suv-lp)]

> graphics glitch which affects flat sided objects which are exactly adjacent.

Already tracked in
Bug #170356 “Suppress antialiasing artefact at the object boundary”
<https://bugs.launchpad.net/inkscape/+bug/170356>

[su_v (suv-lp)]

> Screen shot of the linux specific glitch. One of the bars erroneously
> displayed in white has been selected, notice the fill color shown
> is NOT white.

Not reproduced with current trunk r11656 on OS X 10.7.4 (GTK+ 2.24.10, cairo 1.12.2), tested at various zoom levels including 1015% as shown in the screenshot.

[David Mathog (mathog)]

Further details on linux test:

Inkscape running on Ubuntu 10.04 LTS:

GTK+ 2.24.10
Cairo 1.10.2

to remote display Cygwin X11 Server 1.11.1 on Windows XP.

Tried it from the development system to another 10.04LTS X11 server and that one had the same glitch. Could not get directly onto the console of the development machine at this time, will try later. Could be an X11 transport issue.

[su_v (suv-lp)]

>> Screen shot of the linux specific glitch. One of the bars erroneously
>> displayed in white has been selected, notice the fill color shown
>> is NOT white.

> Inkscape running on Ubuntu 10.04 LTS:
>
> GTK+ 2.24.10
> Cairo 1.10.2

Possibly the same upstream cairo bug as tracked in
Bug #826872 “Rendering artefacts during zooming”
<https://bugs.launchpad.net/inkscape/+bug/826872>

[su_v (suv-lp)]

> Possibly the same upstream cairo bug as tracked in
> Bug #826872 “Rendering artefacts during zooming”

AFAICT this is a duplicate of bug #826872 (upstream bug in cairo) - I can reproduce random fill errors with Inkscape 0.48+devel r11656 on Mac OS X 10.5.8 with cairo 1.10.2.

[su_v (suv-lp)]

<off-topic>
Please try to focus one report= one issue (even if you mistrust the validity of any of my comments).
</off-topic>

[su_v (suv-lp)]

To avoid the anti-aliasing effects (at least at zoom level 100%): align the vertical borders of the stripes to the pixel grid (px = SVG user unit, based on the SVG coordinate system). Thus the edges don't get antialiased against the transparent background, and the seams are not visible.

Very small overlaps (e.g. as small as 0.15 px) might not help to avoid the effect because - depending on zoom level, and even at 100% - some of the edges clearly fall in-between the pixel grid lines of the output device and are rendered antialiased (which affects both sides of the "edge", and thus may have parts of the background showing through), some may not.

[su_v (suv-lp)]

> To avoid the anti-aliasing effects (at least at zoom level 100%):
> align the vertical borders of the stripes to the pixel grid

See e.g. this comment by Bulia Byak (Inkscape developer):
<https://bugs.launchpad.net/inkscape/+bug/166252/comments/5>
any several others in bug #170356 and its duplicate reports.

[su_v (suv-lp)]

Attaching a version of such a sliced gradient which doesn't show seams between adjacent slices at zoom level 100% (1:1), nor when viewed e.g. in Firefox.

(The slices are 2px wide, and aligned to the pixel grid)

[su_v (suv-lp)]

Trying to resolve the status of this report…

- Aligning edges of the slices with the pixel grid helps with zoom level 1:1 (no artifacts).

- Increasing the amount of overlap area increases the range of zoom levels which render without noticeable artifacts:
The most recent version of the omnibus emf patch (bug #988601) seems to create stripes with a slightly bigger overlapping area (0.55-0.60 px) when slicing gradients for EMF export, than the gradients in the example(s) attached here (this is based on a small round-trip of export/import (SVG->EMF->SVG), not on reading the code in the patch). The resulting sliced gradient (vertical stripes with gradually different flat colors) as seen in the imported EMF file now renders in Inkscape without major zoom- (or resolution-)dependent seams (unless one zooms out far enough).

- Not related to cairo (current trunk):
In tests with the two sample files 'graphicsglitch2.svg' and 'graphicsglitch3.svg' using older releases of Inkscape (0.46-0.48.3.1), all of them show the same artifacts (visibly seams between minimally overlapping slices depending on zoom level). Based on what little I know about Inkscape's internal renderer(s), this makes it unlikely a problem in cairo since only the renderer in current trunk uses cairo to render the normal view mode.

Would you agree that this report is about the known antialiasing effects as tracked in bug #170356, even for edges of shapes which are not precisely adjacent but overlap minimally (by a small fraction of a px)?

[su_v (suv-lp)]

A more recent reply (than the comments in bug #170356) by one of the developers on the same topic:
<http://article.gmane.org/gmane.comp.graphics.inkscape.user/14315>

[David Mathog (mathog)]

~suv wrote:

  Would you agree that this report is about the known antialiasing
  effects as tracked in bug #170356, even for edges of shapes which
  are not precisely adjacent but overlap minimally (by a small fraction of a px)?

I think that is very likely the case but cannot be 100% sure since we don't know exactly where this is happening.

The EMF export slicing function breaks any gradient into 128 monochrome pieces (or 129 or 130 if the gradient does not extend all the way across the object and the limits have to be treated specially). Each slice overlaps the two adjacent ones by 1/4 of its width. The glitches described here are seen in macroscopic objects, that is, those of typical size in a typical drawing. If the same method is applied to tiny objects with gradients another problem occurs - EMF files uses integer position coordinates, and truncation/accuracy errors result in a really ragged looking gradient if the tiny object is re-imported and then zoomed up. That's a separate issue.

One thing I have noticed on macroscopic linear gradients is that with the overlap set as described the visual glitches occur with a Moire or "beat" like pattern for certain zooms, but are not so bad at other zooms in between, and that the wavelength of the beat pattern is not always the same. In the attached example the wavelength for 90% zoom is ~1/2 that of 80% zoom, whereas 83% zoom looks smooth. (And 1/2 the zoom of a striped one will also be striped.) My best guess is that slice edge positions are somewhere being set to pixels by truncation rather than by rounding. Once the overlap region is zoomed below 1 px in width then some adjacent slices overlap, while others abut, resulting in the visible pattern. That suggests that extending the overlap to, say, the full width of the next 2 adjacent slices, might ameliorate the problem some - at the expense of extensively overlapping large numbers of small objects.

[Beluga (buovjaga)]

Not seeing this: "occasions where the entire fill of a bar would be shown as white".

I see the white glitch borders on Inkscape and Firefox.

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15073 (GTK3)

[Jonathan Hofinger (jhofinger)]

Hi, this issue is being discussed in https://gitlab.com/inkscape/inkscape/-/issues/928.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.

Closed by: https://gitlab.com/jhofinger