CSC517 OffScreenCanvasContext2D: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 59: Line 59:
* Note: the following command won't work if you're on Janitor.
* Note: the following command won't work if you're on Janitor.


== What we've done ==
=== What we've done ===


As a part of the third project, we’ve already done with the implementation of OffscreenCanvas
As a part of the third project, we’ve already done with the implementation of OffscreenCanvas

Revision as of 04:16, 14 November 2018

About Servo:

Servo is a parallel web-engine project under Mozilla, which aims to develop a web engine to better utilize the potential of multiple processing units to parse and display web-pages faster than conventional browser engines. Servo is implemented using Rust programming language, which is similar to C, except for the fact that it is specially tuned for better memory safety and concurrency features.

Servo makes web-page rendering faster by using parallel layout, styling, web-renders, and constellation. Since, when a thread or javascript of a particular section of the webpage fails, it doesn't affect other tabs, browser or even other elements of the same web-page. So, in a way, Rust lets the browser to "fail better" than other browsers.

Why use rust ?

Algorithms which deal with multiple threads running in parallel are inherently difficult, due to synchronization, data sharing and other typical issues which arise while designing parallel algorithms. C++ makes this process even harder as it does not have efficient mechanisms to deal with this. So, the idea behind rust and servo is to rewrite C++ (and create rust) and use that to rewrite a browser.

Before we get started

Off Screen Canvas:

Canvas is a popular way of drawing all kinds of graphics on the screen and an entry point to the world of WebGL. It can be used to draw shapes, images, run animations, or even display and process video content. It is often used to create beautiful user experiences in media-rich web applications and online games. Because canvas logic and rendering happens on the same thread as user interaction, the (sometimes heavy) computations involved in animations can harm the app’s real and perceived performance.

Until now, canvas drawing capabilities were tied to the <canvas> element, which meant it was directly depending on the DOM. OffscreenCanvas, as the name suggests, decouples the DOM and the Canvas API by moving it off-screen. Due to this decoupling, rendering of OffscreenCanvas is fully detached from the DOM and therefore offers some speed improvements over the regular canvas as there is no synchronization between the two.

Web workers and Offscreen Canvas

Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down. So, JavaScript could run in the background without affecting the performance of the webpage, independent of other scripts. But, web-workers are treated as external files, which makes it impossible for them to access window object, document object and the parent object. Hence, web-workers can only communicate with the rendering-engine by passing messages. But, how is OffscreenCanvas rendered using web-workers?: Suppose the task is to render an image in the canvas. The rendering engine creates a web-worker, and sends it the image data that it needs to process. The web-worker does the required processing, and returns the resultant image back to the rendering-engine. In this way, an image is rendered using an entirely independent process from the webpage.

Web IDL

Web IDL is an interface definition language that can be used to describe interfaces that are intended to be implemented in web browsers. It is an IDL variant with:

  • A number of features that allow one to more easily describe the behavior of common script objects in a web context.
  • A mapping of how interfaces described with Web IDL correspond to language constructs within an ECMAScript execution environment.

Problem Statement:

This document describes the final project of CSC 517 course, that involves merging a few changes into servo, a parallel web browser engine developed by Mozilla. This project builds upon the previous project under CSC, which was also to merge a few changes into servo. For further a detailed information regarding the previous project, please visit: http://wiki.expertiza.ncsu.edu/index.php/CSC517_OffScreenCanvas_Servo.

OffscreenCanvas API is an API which enables the rendering of canvas elements outside the current thread of browser engine or webpage execution. OffscreenCanvas is exactly similar to HTML Canvas, except the fact that it does not have access to DOM and window elements, and it is rendered on a thread completely independent of the main web-page execution. Our task is to implement two interfaces, OffscreenCanvas & OffscreenCanvasContextRendering2D, which would enable this functionality. Then, if the changes made by us are successfully built, the next task is to enable automated tests to check for the accuracy of the code. Finally, we’ll test our code by enabling the blob API.


Getting Started

Building Servo

  • Testing servo requires it to build it locally, or using a cloud service like Janitor.
  • Building servo locally would take approximately 30mins - 1 hour depending upon your computer.
  • For further steps regarding building servo locally, please visit this.

Verifying Build

  • We can verify whether servo has been built by running the following command: ./mach run http://www.google.com
  • This command will render the homepage of google in a new browser instance of servo. If this executes correctly, then the build is fine.
  • Specific functionalities could be tested by writing a custom html file and then running it the similar way.
  • Note: the following command won't work if you're on Janitor.

What we've done

As a part of the third project, we’ve already done with the implementation of OffscreenCanvas interface. We’ve made the corresponding implementation of the webidl file using a rust file, and have also enabled and passed the automated tests. We’ve also made the interface for OffscreenCanvasContextRendering2D.

Proposed Design

As a part of the fourth project, we’ve planned to first make an implementation for the OffscreenCanvasContextRendering2D file that we’ve created. This the the file which would perform all the rendering in the back-end. Since OffscreenCanvas is very similar to HTML canvas, we’ll first copy the code from HTMLCanvasContextRendering2D, and paste it into our implementation. We would then filter out the code which is not a part of the OffscreenCanvasContextRendering2D, and then add the functionalities that should be present. Finally, we would implement the blob API, which would enable us to test the contents of the canvas. Then, similarly, we would support webgl contexts, in a manner similar to the 2D context, by sharing relevant code between OffscreenCanvasRenderingContext2D and WebGLRenderingContext.

Files we've changed and to-be changed

1. OffscreenCanvas.webidl
2. OffscreenCanvas.rs
3. OffscreenCanvasContextRendering2D.webidl
4. OffscreenCanvasCOntextRendering2D.rs
5. resources/prefs.json
6. tests/wpt/include.ini
7. ___dir___.ini

References:

1. https://research.mozilla.org/servo-engines/
2. https://research.mozilla.org/rust/
3. https://hacks.mozilla.org/2017/05/quantum-up-close-what-is-a-browser-engine/