Currently, Servo struggles a lot with rendering Cookie Clicker's canvases, especially when there are actions going on, and so far, I have explored three areas of interest:

• ctx.fillText and 2D canvas text rendering (lag caused by text particles) (to be split off to its own issue)
  • I suspect that it would be interesting to replace some of its logic with more standard ones; maybe using HarfBuzz could help? Who knows; I just know that by effectively unimplementing the feature, it ended exposing itself as a bottleneck for rendering, and by disabling the "Numbers" option, this same lag is alleviated
• ctx.drawImage (lag caused by an excess of images, easily caused by cookie particles)

  • This affects anything involving drawing an image to the 2D canvas, and after digging a lot? I could determine the culprit being the way the image data is being fed to canvas::canvas_data::draw_image

    Seeing how WebGL had handled a similar situation, I decided to try something and so I replaced the ByteBuf with the image pixels' IpcSharedMemory in a really messy way; the lag ends being greatly reduced on Steam's browser version, although the online browser version locks itself once a language is chosen

    I suspect that a proper solution would be replacing the transferring of image data with the transferring of ImageKeys somehow; I still have to dig further into how the other areas handle this scenario

• The 2D canvas backend (currently raqote) (split off to Investigate other 2D canvas renderers in a post-Pathfinder world #30636)

  • Unfortunately, Pathfinder appears to be a dead project now; however, software rendering doesn't need to be that bad;

    On the process of thinking about potential optimization, I remembered that tiny_skia existed as an alternative and it did promise faster performance compared to raqote; but promises are promises, so I decided to mess around with a prototype of a tiny_skia backend, and it works! for Cookie Clicker and Cookie Clicker only! It currently fails a lot of WPT tests, the whole code is a mess, and the canvas code will need to be adapted for it (and the absence of the azure backend), but it does seem promising!

    I'm still not on a point where I can say "tiny_skia is definitely better than raqote", but considering the slight performance gains that I got despite the bottlenecks and considering that tiny_skia appears to be the more used/better-maintained crate nowadays, I find it something to be considered

For testing against potential bottlenecks, the Steam version's copy of the browser version (the Steam additions are a separate patch on top of it) proved to be indispensable for quickly iterating through solutions

Maybe these points should be split into separate issues once more progress is made