Canvas rendering project

Simplify the 2d canvas renderer

Background information: The HTML specification defines a <canvas> element that can use a 2d or 3d rendering context. Servo's implementation contains several inefficiencies that make some websites perform slowly or run out of memory when performing complex canvas operations. The goal of this project is to make these websites perform better when loaded in Servo.

Tracking issues (please ask questions here):

• https://github.com/servo/servo/issues/10381
• https://github.com/servo/servo/issues/13879

Initial steps:

• email the mozilla.dev.servo mailing list (be sure to subscribe to it first!) introducing your group and asking any necessary questions
• create a testcase that contains two canvases and uses the drawImage API to draw the contents of one canvas onto the other. Programmatically measure the time this operation takes.
• To prepare for the big switch from 1 threads per canvas to 1 thread for all canvases, add a struct CanvasId(u64) type to components/canvas_traits/canvas.rs and add a CanvasId member to each variant of the CanvasMsg enum.
• add a CanvasId member to Constellation in components/constellation/constellation.rs which is initialized to 0 and increased by 1 each time handle_create_canvas_paint_thread is called.
• make the response_sender argument of handle_create_canvas_paint_thread also include the new CanvasId value, and pass it as an argument to CanvasPaintThread::start. Store the id when it is received for use in all canvas messages.
• For each CanvasMsg that is processed by CanvasPaintThread, verify that the id received matches the id that was provided to CanvasPaintThread::start

Subsequent steps:

• extract the innards of CanvasPaintThread into a CanvasData structure,
• make CanvasPaintThread store a hashtable of CanvasId->CanvasData
• as part of Constellation::start, create a canvas paint thread and store the channel to communicate with it as a member of Constellation. Remove the initial canvas id from the API of Constellation::start.
• when handle_create_canvas_paint_thread is invoked, communicate with the canvas thread and have it create a new entry in the hashtable.
• when the canvas thread receives a message, perform the operation on the appropriate canvas according to the provided id
• optimize the DrawImageInOther operation by drawing on the destination canvas directly, rather than relying on sending a message to another canvas thread. Remove the now-unnecessary IpcSender from the DrawImageInOther enum variant. Verify that the earlier testcase demonstrates a performance improvement.
• report on how slither.io performs in Servo after all these changes