-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gaps sometimes visible between filled paths which share an edge #542
Comments
Wow a very good bug report! I want to look at this more in what Cairo or Context do. I want to see if this issue can be fixed. Some on the edge of our fills with AA is not quite right. |
I only have a minute to reply but the short version is that this is two separate issues: For when there are two paths (or two SVG strings), the issue is premultiplied alpha compositing, this is basically unavoidable due to Pixie storing premulitplied alpha color values. I think filling each separate path into separate images and then compositing those images may produce better output but I would need to test. (Don't fill the image with black first if you want good color AA as well, draw the final composited image in top of a black image at the very end to avoid the black tainting the compositing steps.) For CW-CCW alternation, this is intersection floating point values not perfectly matching and thus having tiny tiny tiny gaps leading to non-255 coverage. Both are extremely hard or impossible to fix without changing internal things to Pixie. These are basically the antagonistic cases for complex path filling. One quick example I could find https://graphicdesign.stackexchange.com/questions/65058/image-looks-embossed-when-converted-to-svg |
Upon a quick test, I could not see a difference with either compositing onto a black backing image, or drawing each shape into a separate image composited into one, and then onto black. But indeed those are good practices, and I will play around more. While I don't know anything about Pixie's internals, I'm wondering if something like Fast Robust Predicates for Computational Geometry may be of any use around the floating point issues. I recently ported Mapbox's Delaunator to Nim, and it uses a ported version to achieve robustness around degenerate input. A tough problem indeed. For a possibly imprecise solution, here is the above image with added strokes at a width of 1.5, composited shape by shape as suggested above: |
Greetings, and thank you for sharing Pixie!
I am not sure if this is to be expected or not (or even whether cairo shows similar behavior), although there are inconsistencies within pixie's behavior at minimum. Here is a 4x2 grid showcasing the behavior. Each cell is essentially filled with two white triangles, and sometimes a gap is visible between them even though their shared edge is specified from the same points. In case it is not obvious which cells due to monitor dpi or brightness:
For the top row,
cw
, andccw
refers to whether a triangle's path was specified in a clockwise or counter-clockwise manner. Each top row example is a single filled path.For the second row, each example left to right:
Vertical and horizontal fills don't seem to exhibit this behavior, only diagonals.
The code which produced this image:
In an image full of filled paths, this behavior makes it look as though strokes were applied when they were not. For example:
If you look closely, there are a few spots in the above image where 'strokes' seem to be missing. These are areas where shared edges are closely vertical or horizontal.
I assume this has everything to do with AA of fills. Thanks for taking a look.
The text was updated successfully, but these errors were encountered: