[haiku-bugs] Re: [Haiku] #17538: WebPositive SVG stroke rendering

  • From: "Haiku" <trac@xxxxxxxxxxxx>
  • To: undisclosed-recipients: ;
  • Date: Tue, 25 Jan 2022 14:14:06 -0000

#17538: WebPositive SVG stroke rendering
-------------------------------------+-------------------------------------
  Reporter:  thebuck                 |      Owner:  pulkomandy
      Type:  bug                     |     Status:  new
  Priority:  normal                  |  Milestone:  Unscheduled
 Component:                          |    Version:  R1/Development
  Applications/WebPositive           |   Keywords:  SVG stroke line
Resolution:                          |  rendering
Blocked By:                          |   Blocking:
  Platform:  All                     |
-------------------------------------+-------------------------------------
Description changed by thebuck:

Old description:

The handcrafted stroke-test.svg uncovers many stroke-related rendering
issues, see Conclusions section.

Using the test image:\\
- View it standalone in WebPositive to test mouse hover effects and to
avoid #17305.\\
- Every assymmetry (except color change on mouse hover) with respect to
the vertical red line is a browser bug.\\

Elements of the image (left | right):\\
- orange top: filled rectangular path | stroked line path\\
- blue top U: just one curve path\\
- black O: differently scaled quarter paths with their stroke-width and
geometry adjusted to make them look identical; \\listing stroke-width:\\
 - top:     4 | 0.125\\
 - bottom: 16 | 2.5\\
- blue bottom: line path segments | one dashed line path\\
- While the mouse is over an element, the element becomes green.\\

Conclusions from my hrev55788/x86_64/QEMU test run:
1. If 0 < stroke-width < 1 then it renders as 1.
2. transform is neglected for path polygonization detail level (same for
fill).
3. stroke-dasharray is unimplemented.
4. The combination "fill:none;stroke:#000" causes over-stroking with last
non-none fill color, i.e. **two** layers of stroke are painted.
5. Renderer's bounding box of paths neglects stroke (however, extreme
points of curves extend the box more than enough).
6. LCD subpixel antialiasing preference generally affects SVG (should
always greyscale like other browsers)

What tests led to conclusions:
1. The magenta zero-stroke thing is invisible, the O has thick top right
(0.125 as 1), and bottom right was correctly not rounded to int (2.5).
2. The number of polylines (look carefully for corners) in O quarters
increases with stroke-width, i.e. with less upscaling
3. The bottom blue right half is continuous, also for mouse hover
detection (thin hover area because of 5.).
4. Scrolling the bounding box of the top left orange rectangle in/out of
view toggles orange overpainting of all black elements (resize window for
this; with LCD subpixel antialiasing the second paint layer becomes
noticeable).
5. Hovering the mouse over elements works only in their bounding box and
repaints only the same (test especially blue elements; move between them
and the red cross to get larger repaints).
6. Change antialiasing preference and reload page.

New description:

 The handcrafted stroke-test.svg uncovers many stroke-related rendering
 issues, see Conclusions section.

 Using the test image:\\
 - View it standalone in WebPositive to test mouse hover effects and to
 avoid #17305.\\
 - Every assymmetry (except color change on mouse hover) with respect to
 the vertical red line is a browser bug.\\

 Elements of the image (left | right):\\
 - orange top: filled rectangular path | stroked line path\\
 - blue top U: just one curve path\\
 - black O: differently scaled quarter paths with their stroke-width and
 geometry adjusted to make them look identical; \\listing stroke-width:\\
  - top:     4 | 0.125\\
  - bottom: 16 | 2.5\\
 - blue bottom: line path segments | one dashed line path\\
 - While the mouse is over an element, the element becomes green.\\

 Conclusions from my hrev55788/x86_64/QEMU test run:
 1. If 0 < stroke-width < 1 then it renders as 1.
 2. transform is neglected for path polygonization detail level (same for
 fill).
 3. stroke-dasharray is unimplemented.
 4. The combination "fill:none;stroke:#000" causes over-stroking with last
 non-none fill color, i.e. **two** layers of stroke are painted.
 5. Renderer's bounding box of paths neglects stroke (however, extreme
 points of curves extend the box more than enough).
 6. LCD subpixel antialiasing preference generally affects SVG (should
 always greyscale like other browsers).
 7. The fill-rule equivalent for stroking is uninitialized (should be
 nonzero).

 What tests led to conclusions:
 1. The magenta zero-stroke thing is invisible, the O has thick top right
 (0.125 as 1), and bottom right was correctly not rounded to int (2.5).
 2. The number of polylines (look carefully for corners) in O quarters
 increases with stroke-width, i.e. with less upscaling
 3. The bottom blue right half is continuous, also for mouse hover
 detection (thin hover area because of 5.).
 4. Scrolling the bounding box of the top left orange rectangle in/out of
 view toggles orange overpainting of all black elements (resize window for
 this; with LCD subpixel antialiasing the second paint layer becomes
 noticeable).
 5. Hovering the mouse over elements works only in their bounding box and
 repaints only the same (test especially blue elements; move between them
 and the red cross to get larger repaints).
 6. Change antialiasing preference and reload page.
 7. The red cross has a transparent center. I also saw that effect
 triggered by an unrelated transition somewhere else, without nearby "fill-
 rule:evenodd".

--
-- 
Ticket URL: <https://dev.haiku-os.org/ticket/17538#comment:2>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.

Other related posts: