| | [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #3476
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| 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 artecfacts under certain conditions (rounding?) |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | chris |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #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. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
