Optimize save-transform-constructPath-restore

[calixteman]

The 4 operations can be replaced with just one in applying the transform to the points coordinates.

[calixteman]

/botio test

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_test from @calixteman received. Current queue size: 0

Live output at: http://54.193.163.58:8877/080fffefa04d659/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_test from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/0b06274035d985b/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/0b06274035d985b/output.txt

Total script time: 29.95 mins

• Unit tests: Passed
• Integration Tests: FAILED
• Regression tests: FAILED

  different ref/snapshot: 60

Image differences available at: http://54.241.84.105:8877/0b06274035d985b/reftest-analyzer.html#web=eq.log

[Snuffleupagus]

• Even though the changes look imperceivable to the naked eye, do we expect movement in "so many" cases simply from a different chunking of the path rendering operators?
• Any examples of PDFs where this help improve performance, and perhaps also some benchmarking results for this patch?

[calixteman]

The "improvement" was a way better when the patch was merging similar constructPath, but as mentioned in general it doesn't work. That said if we're able to know in the worker, that we aren't composing, then we should be able to do something better.
So about the current patch, it mainly helps to remove useless operations.
For example, with issue17779.pdf, on Windows 11, it helps to win ~0.8s when the overall rendering takes 18s:

• with the patch: https://share.firefox.dev/4kV856T
• without: https://share.firefox.dev/4iXagoF
  So it isn't crazy for sure but probably better than nothing.