{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":742074000,"defaultBranch":"main","name":"z2d","ownerLogin":"vancluever","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2024-01-11T17:55:43.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/10704423?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1725038616.0","currentOid":""},"activityList":{"items":[{"before":"91c454d7d0b50dd5a529b0a9506ddd770b87e5c3","after":"77f15d12c614662d85f264cbc61a2380c52cfaf1","ref":"refs/heads/main","pushedAt":"2024-08-30T17:23:34.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Bump CHANGELOG.md to v0.2.1-pre","shortMessageHtmlLink":"Bump CHANGELOG.md to v0.2.1-pre"}},{"before":"68fd80169265b95b7e1fd455f29850e694c09d3d","after":"91c454d7d0b50dd5a529b0a9506ddd770b87e5c3","ref":"refs/heads/main","pushedAt":"2024-08-30T16:25:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Update CHANGELOG.md","shortMessageHtmlLink":"Update CHANGELOG.md"}},{"before":"0715a2d97fb621f7da13df6678b5e455bd80ff6b","after":"68fd80169265b95b7e1fd455f29850e694c09d3d","ref":"refs/heads/main","pushedAt":"2024-08-30T16:10:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Polygon: ensure extents are updated on concat\n\nWe weren't updating on concat, which ultimately meant that any polygons\nthat were being combined with extents that were lower on the y-boundary\nwould ultimately get clipped during rasterization.\n\nFixes #41.","shortMessageHtmlLink":"Polygon: ensure extents are updated on concat"}},{"before":"8fe1d6b98a5beb3d6908f1c594cb2e3e0270c97d","after":"0715a2d97fb621f7da13df6678b5e455bd80ff6b","ref":"refs/heads/main","pushedAt":"2024-08-29T18:59:55.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Update README.md (grammar change)","shortMessageHtmlLink":"Update README.md (grammar change)"}},{"before":"77b1d51636c806041f644ff798bf6b71553675f1","after":"8fe1d6b98a5beb3d6908f1c594cb2e3e0270c97d","ref":"refs/heads/main","pushedAt":"2024-08-29T18:56:49.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"README update to reflect current status","shortMessageHtmlLink":"README update to reflect current status"}},{"before":"0a040b0ba4f9dd059fdc5de5b0be4af305badf79","after":"77b1d51636c806041f644ff798bf6b71553675f1","ref":"refs/heads/main","pushedAt":"2024-08-29T18:06:09.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: Handle zero-length segments in join\n\nFixes #40\n\nThis ensures that zero-length segments (e.g., p0 -> p1 is equal, or p1\n-> p2 are equal) are skipped during adding joins (there's technically\nnothing to join). This was causing assertion failures before.","shortMessageHtmlLink":"StrokePlotter: Handle zero-length segments in join"}},{"before":"f7fbb5d14e29d7ee144375031a48991e918bf34d","after":"0a040b0ba4f9dd059fdc5de5b0be4af305badf79","ref":"refs/heads/main","pushedAt":"2024-08-29T17:30:22.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: support zero-length strokes\n\nThis adds support for zero-length strokes as per the SVG spec and Cairo\nbehavior.\n\nNote that this currently only includes the round cap case, as that's the\nonly one we can support currently, as we don't do dashed strokes at the\nmoment.","shortMessageHtmlLink":"StrokePlotter: support zero-length strokes"}},{"before":"00d33564104b7832d4ee1d9cb6689967d0a7656c","after":"f7fbb5d14e29d7ee144375031a48991e918bf34d","ref":"refs/heads/main","pushedAt":"2024-08-29T01:09:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Face: add assertion for intersect","shortMessageHtmlLink":"Face: add assertion for intersect"}},{"before":"90130bd46990b28fefb08a9406fe1def9449c9bd","after":"00d33564104b7832d4ee1d9cb6689967d0a7656c","ref":"refs/heads/main","pushedAt":"2024-08-29T00:59:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Face: simplify intersection logic\n\nThis removes all of the special-case and intercept-based intersection\nlogic from Face.zig, replacing it with a more generalized version.\n\nThe intersection equation has been taken from Cairo, as they have a good\nreduction that allows the intersection to be calculated via first\ncalculating the y-coordinate, and then calculating the x-coordinate from\nthe larger y-delta between the inbound and outbound faces. Cairo does\nthis to prevent division close to zero, and as such it works when one of\nthe faces represents a horizontal line.\n\nThis has also allowed us to remove the special-case initialization as\nwell, and even with this, none of the acceptance tests have changed, so\nany slight differences that may happen due to generalization of offsets\nhas no ultimate effect.\n\n(Note that it's possible that when we eventually implement\ntransformations, this could have had an impact, but in that sense, it's\nbetter this change now versus then.)","shortMessageHtmlLink":"Face: simplify intersection logic"}},{"before":"155619d27d392ad7a184c0deac0e0d9785d950fe","after":"90130bd46990b28fefb08a9406fe1def9449c9bd","ref":"refs/heads/main","pushedAt":"2024-08-24T19:58:57.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: some semantics changes, removal of not needed state\n\nWe've calculated a single direction for the larger polygon for a long\ntime now (based on the first join's direction), but we still had\nleft over state for the start and end directions of a particular\npolygon. This removes that and also fixes some semantics in the join\nmethod so that it's clear how the method handles direction.","shortMessageHtmlLink":"StrokePlotter: some semantics changes, removal of not needed state"}},{"before":"c78a5236a18bafaf522f7c121b0d6c43202fb8bf","after":"155619d27d392ad7a184c0deac0e0d9785d950fe","ref":"refs/heads/main","pushedAt":"2024-08-24T19:45:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: ensure later co-linear points plot correctly\n\nThis ensures co-linear points are plotted correctly if they are\nencountered after non-co-linear points are plotted and a larger polyline\ndirection is already established.","shortMessageHtmlLink":"StrokePlotter: ensure later co-linear points plot correctly"}},{"before":"07886a4a2d3bce81c864bb04cbdb79b7627f50cc","after":"c78a5236a18bafaf522f7c121b0d6c43202fb8bf","ref":"refs/heads/main","pushedAt":"2024-08-24T01:44:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"spec: add a couple of other co-linearity test cases\n\nThis adds paths that \"switch back\" to a section inside the adjacent edge\nand is technically co-linear, even though the slopes aren't the same\n(they differ by exactly pi).","shortMessageHtmlLink":"spec: add a couple of other co-linearity test cases"}},{"before":"c690797960ba91ad2d3070c3a5740a08cc6315a3","after":null,"ref":"refs/heads/fix-inner-join","pushedAt":"2024-08-23T22:52:34.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"}},{"before":"8319cfd9cb9be0f3049c7038a0e9b3d9074cfd50","after":"07886a4a2d3bce81c864bb04cbdb79b7627f50cc","ref":"refs/heads/main","pushedAt":"2024-08-23T22:52:33.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Merge pull request #39 from vancluever/fix-inner-join\n\nStrokePlotter: new inner join behavior","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2483999539\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vancluever/z2d/issues/39\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vancluever/z2d/pull/39/hovercard\" href=\"https://github.com/vancluever/z2d/pull/39\">#39</a> from vancluever/fix-inner-join"}},{"before":null,"after":"c690797960ba91ad2d3070c3a5740a08cc6315a3","ref":"refs/heads/fix-inner-join","pushedAt":"2024-08-23T22:49:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: new inner join behavior\n\nThis fixes inner joins so that they behave like they do in most other\ngraphics libraries, in that rather than attempting to take the\nintersection of the two inside faces/edges of a join, the polygon edges\nare actually traced through the endpoints of each line as if they were\nunjoined, going through the midpoint.\n\nThis creates edges that overlap and give the same effect, while avoiding\nedge cases on very acute angles where stokes may actually overlap on the\ninside, and as such their inner faces technically do not intersect at\nall.","shortMessageHtmlLink":"StrokePlotter: new inner join behavior"}},{"before":"343d9cc0243734baa436f262e3db3fdb7e460392","after":"8319cfd9cb9be0f3049c7038a0e9b3d9074cfd50","ref":"refs/heads/main","pushedAt":"2024-08-22T16:36:48.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Move to Zig 0.13.0","shortMessageHtmlLink":"Move to Zig 0.13.0"}},{"before":"ee8be12d54266e0d1a688a33316a8c65469e62e1","after":null,"ref":"refs/heads/stroke-colinear","pushedAt":"2024-08-14T00:39:59.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"}},{"before":"4e2813fc01c6554e5ce53dac93c829b5f8e1a536","after":"343d9cc0243734baa436f262e3db3fdb7e460392","ref":"refs/heads/main","pushedAt":"2024-08-14T00:39:58.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Merge pull request #38 from vancluever/stroke-colinear\n\nStrokePlotter: handle co-linear joins","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2464566151\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vancluever/z2d/issues/38\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vancluever/z2d/pull/38/hovercard\" href=\"https://github.com/vancluever/z2d/pull/38\">#38</a> from vancluever/stroke-colinear"}},{"before":"7dd614ea45e60cd68f5c259d60194bd9cb2c714c","after":"ee8be12d54266e0d1a688a33316a8c65469e62e1","ref":"refs/heads/stroke-colinear","pushedAt":"2024-08-14T00:39:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: handle co-linear joins\n\nFixes #37\n\nThis fixes co-linear joins by just plotting the end point of the inbound\nface, regardless of the join type (this case holds for every type as the\nangle between the inbound and outbound lines would always be 180\ndegrees).\n\nAdditionally, due to the fact that we can't specifically tell if a\nco-linear join is clockwise or counter-clockwise, we defer the\ndetermination of rotational direction until a point that we can actually\ndetermine it. If it never is determined (i.e., the path is essentially\njust a straight line), we just assume counter-clockwise (derived from\nour calculation of cw = in.slope.compare(out.slope) < 0).","shortMessageHtmlLink":"StrokePlotter: handle co-linear joins"}},{"before":"a5ac95c46c23d595714ba0dd0fc8416fe64d1ffb","after":"7dd614ea45e60cd68f5c259d60194bd9cb2c714c","ref":"refs/heads/stroke-colinear","pushedAt":"2024-08-14T00:29:00.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: handle co-linear joins\n\nFixes #37\n\nThis fixes co-linear joins by just plotting the end point of the inbound\nface, regardless of the join type (this case holds for every type as the\nangle between the inbound and outbound lines would always be 180\ndegrees).\n\nAdditionally, due to the fact that we can't specifically tell if a\nco-linear join is clockwise or counter-clockwise, we defer the\ndetermination of rotational direction until a point that we can actually\ndetermine it. If it never is determined (i.e., the path is essentially\njust a straight line), we just assume counter-clockwise (derived from\nour calculation of cw = in.slope.compare(out.slope) < 0).","shortMessageHtmlLink":"StrokePlotter: handle co-linear joins"}},{"before":null,"after":"a5ac95c46c23d595714ba0dd0fc8416fe64d1ffb","ref":"refs/heads/stroke-colinear","pushedAt":"2024-08-14T00:27:58.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"StrokePlotter: handle co-linear joins\n\nFixes #37\n\nThis fixes co-linear joins by just plotting the end point of the inbound\nface, regardless of the join type (this case holds for every type as the\nangle between the inbound and outbound lines would always be 180\ndegrees).\n\nAdditionally, due to the fact that we can't specifically tell if a\nco-linear join is clockwise or counter-clockwise, we defer the\ndetermination of rotational direction until a point that we can actually\ndetermine it. If it never is determined (i.e., the path is essentially\njust a straight line), we just assume counter-clockwise (derived from\nour calculation of cw = in.slope.compare(out.slope) < 0).","shortMessageHtmlLink":"StrokePlotter: handle co-linear joins"}},{"before":"c273a7245e4f3ce10b26abccb5becb47f6dbf068","after":"f395355026016dec35c1343bab2fd3fba8de153c","ref":"refs/heads/svg","pushedAt":"2024-07-17T16:23:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"add test for parsing fill/stroke color","shortMessageHtmlLink":"add test for parsing fill/stroke color"}},{"before":"3df0e65640d9019cfbc9bacab49d6bbea951fa76","after":"4e2813fc01c6554e5ce53dac93c829b5f8e1a536","ref":"refs/heads/main","pushedAt":"2024-07-17T16:20:25.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: more arc docstring fixes","shortMessageHtmlLink":"Path: more arc docstring fixes"}},{"before":"9584760f74dc8e46d70ad0cfc4fc9ba4aba46dae","after":"3df0e65640d9019cfbc9bacab49d6bbea951fa76","ref":"refs/heads/main","pushedAt":"2024-07-17T16:11:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: Grammar correction on arc documentation","shortMessageHtmlLink":"Path: Grammar correction on arc documentation"}},{"before":"c46aa51e683edf51930e19eceee44a641a1a0d07","after":null,"ref":"refs/heads/arc","pushedAt":"2024-07-17T16:04:41.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"}},{"before":"8d7750b7d0f9d77fd549e7740786b410dbf49a8a","after":"9584760f74dc8e46d70ad0cfc4fc9ba4aba46dae","ref":"refs/heads/main","pushedAt":"2024-07-17T16:04:39.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Merge pull request #36 from vancluever/arc\n\nPath: add arc support","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2412400118\" data-permission-text=\"Title is private\" data-url=\"https://github.com/vancluever/z2d/issues/36\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/vancluever/z2d/pull/36/hovercard\" href=\"https://github.com/vancluever/z2d/pull/36\">#36</a> from vancluever/arc"}},{"before":"5a5fd3c5ccd3e6f48d8e34bd89f815aafd1dc710","after":"c46aa51e683edf51930e19eceee44a641a1a0d07","ref":"refs/heads/arc","pushedAt":"2024-07-17T16:02:53.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: add arc support\n\nThis adds support for arcs for Paths (drawing of circles, and eventually\nellipses once we add transformations).\n\nLike Cairo, arcs are not added as path primitives themselves. Rather,\nthe arc function is a helper for finding the best-fit approximation of\nthe arc using splines within a specified tolerance (can be provided, but\nis optional; if not, the default tolerance is used). The arc\napproximation logic has been taken from Cairo\n(attribution/acknowledgment in file).\n\nThe API is similar to Cairo, but the normal/negative methods have been\ncondensed into one. This may not be set in stone; I'm contemplating\nadding shorthand normal/negative/default tolerance methods.\n\nAlso, regarding tolerance: the main reason we require this in the method\nis that we de-couple Path and Context. As such, we cannot take the\ntolerance from the context. This implementation detail is only slightly\ninconvenient I think, and there are notes in the method description to\ninstruct on when it should be changed from the default, and where to find\nit in the context. It should be noted that it appears that Cairo itself\nonly takes the value upon execution of the arc functions, so if you add\narcs, and then change tolerance after, the drift will not be reflected\nin the approximations (the splines will have already been written to the\npath).","shortMessageHtmlLink":"Path: add arc support"}},{"before":"a58de6ba62472d7978ffe01f35ba27688203d562","after":"5a5fd3c5ccd3e6f48d8e34bd89f815aafd1dc710","ref":"refs/heads/arc","pushedAt":"2024-07-17T01:40:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: add arc support\n\nThis adds support for arcs for Paths (drawing of circles, and eventually\nellipses once we add transformations).\n\nLike Cairo, arcs are not added as path primitives themselves. Rather,\nthe arc function is a helper for finding the best-fit approximation of\nthe arc using splines within a specified tolerance (can be provided, but\nis optional; if not, the default tolerance is used). The arc\napproximation logic has been taken from Cairo\n(attribution/acknowledgment in file).\n\nThe API is similar to Cairo, but the normal/negative methods have been\ncondensed into one. This may not be set in stone; I'm contemplating\nadding shorthand normal/negative/default tolerance methods.\n\nAlso, regarding tolerance: the main reason we require this in the method\nis that we de-couple Path and Context. As such, we cannot take the\ntolerance from the context. This implementation detail is only slightly\ninconvenient I think, and there are notes in the method description to\ninstruct on when it should be changed from the default, and where to find\nit in the context. It should be noted that it appears that Cairo itself\nonly takes the value upon execution of the arc functions, so if you add\narcs, and then change tolerance after, the drift will not be reflected\nin the approximations (the splines will have already been written to the\npath).","shortMessageHtmlLink":"Path: add arc support"}},{"before":"a1b8266ffa1e9e1809f92dda0fba2bf77e787f61","after":"a58de6ba62472d7978ffe01f35ba27688203d562","ref":"refs/heads/arc","pushedAt":"2024-07-17T01:37:02.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: add arc support\n\nThis adds support for arcs for Paths (drawing of circles, and eventually\nellipses once we add transformations).\n\nLike Cairo, arcs are not added as path primitives themselves. Rather,\nthe arc function is a helper for finding the best-fit approximation of\nthe arc using splines within a specified tolerance (can be provided, but\nis optional; if not, the default tolerance is used). The arc\napproximation logic has been taken from Cairo\n(attribution/acknowledgment in file).\n\nThe API is similar to Cairo, but the normal/negative methods have been\ncondensed into one. This may not be set in stone; I'm contemplating\nadding shorthand normal/negative/default tolerance methods.\n\nAlso, regarding tolerance: the main reason we require this in the method\nis that we de-couple Path and Context. As such, we cannot take the\ntolerance from the context. This implementation detail is only slightly\ninconvenient I think, and there are notes in the method description to\ninstruct on when it should be changed from the default, and where to find\nit in the context. It should be noted that it appears that Cairo itself\nonly takes the value upon execution of the arc functions, so if you add\narcs, and then change tolerance after, the drift will not be reflected\nin the approximations (the splines will have already been written to the\npath).","shortMessageHtmlLink":"Path: add arc support"}},{"before":"77bc5f80ab917729105ea477c2d11531628e7e7f","after":"a1b8266ffa1e9e1809f92dda0fba2bf77e787f61","ref":"refs/heads/arc","pushedAt":"2024-07-17T01:30:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vancluever","name":"Chris Marchesi","path":"/vancluever","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/10704423?s=80&v=4"},"commit":{"message":"Path: add arc support\n\nThis adds support for arcs for Paths (drawing of circles, and eventually\nellipses once we add transformations).\n\nLike Cairo, arcs are not added as path primitives themselves. Rather,\nthe arc function is a helper for finding the best-fit approximation of\nthe arc using splines within a specified tolerance (can be provided, but\nis optional; if not, the default tolerance is used). The arc\napproximation logic has been taken from Cairo\n(attribution/acknowledgment in file).\n\nThe API is similar to Cairo, but the normal/negative methods have been\ncondensed into one. This may not be set in stone; I'm contemplating\nadding shorthand normal/negative/default tolerance methods.\n\nAlso, regarding tolerance: the main reason we require this in the method\nis that we de-couple Path and Context. As such, we cannot take the\ntolerance from the context. This implementation detail is only slightly\ninconvenient I think, and there are notes in the method description to\ninstruct on when it should be changed from the default, and where to find\nit in the context. It should be noted that it appears that Cairo itself\nonly takes the value upon execution of the arc functions, so if you add\narcs, and then change tolerance after, the drift will not be reflected\nin the approximations (the splines will have already been written to the\npath).","shortMessageHtmlLink":"Path: add arc support"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEqOXCSAA","startCursor":null,"endCursor":null}},"title":"Activity · vancluever/z2d"}