| [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3476
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Image Support |
Summary: | nanosvg: rendering artefacts under certain conditions (rounding?) |
Version: | 1.4-feature |
Created By: | chris |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | 384b546dc68d5767c0862f364d66e297500848c6 |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | chris 23:08 Jun 13, 2018 |
| As exposed in the thread "A nice analog clock using nanoSVG" in fltk.general at:
https://groups.google.com/forum/#!topic/fltkgeneral/OMkCAqk1qY0
nanosvg does not render certain images correctly.
Some debugging led me to the conclusion that the artefacts are introduced at the rasterization stage and are most probably caused by rounding errors due to fixed integer arithmetic.
I attach a simple test svg 'linecap.svg' that shows the effect: the rounded line cap at the bottom of the line is shifted 2 pixels to the left without any obvious reason. The error is very dependant on the angle of the line -> if the coordinates changes only slighty the error often goes away completely.
You can view this file e.g. with the pixmap_browser test program to see the artefact.
As a potential fix, I found changing the define for NSVG__FIXSHIFT in 'nanosvgrast.h' to 14 (currently 10) makes the artefacts disappear.
To explain, let me simply cite Ian (Mac Arthur)'s response from the above mentioned thread:
--- "Well, it's a fixed-point number system, using integer maths: By default they are using a shift of 10 bits, so assuming we are using a 32-bit integer (which seems like a safe assumption for now...) then we have (setting aside the effect of sign bits etc) effectively 22-bits of "integer" part and 10-bits of "fractional" part. (Or, 21-bits of usable integer range, plus the sign bit...)
By setting FIXSHIFT larger, you are making for more resolution in the fractional part, but at the cost of less range in the integral part - something like 17-bits of integral range (plus the sign.)
Now, 17-bits of integral range might well be enough for a lot of pictures, so maybe that is OK?" ---
As I read it, this change would still leave more than 130000 (2^17) pixel range available, IMHO this should be enough for any picture. | |
|
#2 | AlbrechtS 10:45 Dec 13, 2023 |
| Fixed in Git repository.
Fix commit: 384b546dc68d5767c0862f364d66e297500848c6, nanosvg docs (README) updated in a6927779c34f654da91dd559be2b42b00409b1d8.
Note: fixed in FLTK 1.3 as well.
The update to the latest version of nanosvg fixed this STR - mostly. There are AFAICT still tiny (much smaller) artifacts in some positions (angles) of the hands of Greg's clock (see linked thread in fltk.general) but I can't see anything wrong in the posted image 'linecap.svg'.
This was to be expected, taking the fixes (and remaining issues) discussed on the nanosvg GitHub issues and PR's into account. Thanks, Chris, for your PR and other comments to the nanosvg repo, BTW.
As I read and understand it there were some rounding fixes accepted but your NSVG__FIXSHIFT patch didn't get applied. I decided not to change this in our (FLTK's) fork because the issue is now only marginal (our fork of nanosvg is used to track our own patches and merged into the FLTK sources).
We try to follow nanosvg upstream as close as possible with currently only two patches.
I'm closing this STR now. If there are any other issues please open a GitHub issue. Thanks. | |
[ Return to Bugs & Features ]
|
| |