CSC517 OffScreenCanvas Servo: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 13: Line 13:


The HTML specification defines a <canvas> element that can use a 2d or 3d rendering context. A new specification was recently developed that defines a canvas that can be used without being associated with an in-page canvas element, allowing for more efficient rendering. To use the OffscreenCanvas API, we have used a RenderingContext that has been obtained from an OffscreenCanvas object to generate new frames. Once a new frame has finished rendering in this context,  the transferToImageBitmap() method can be called to save the most recent rendered image. This method returns an ImageBitmap object, which can be used in a variety of Web APIs and also in a second canvas without creating a transfer copy.
The HTML specification defines a <canvas> element that can use a 2d or 3d rendering context. A new specification was recently developed that defines a canvas that can be used without being associated with an in-page canvas element, allowing for more efficient rendering. To use the OffscreenCanvas API, we have used a RenderingContext that has been obtained from an OffscreenCanvas object to generate new frames. Once a new frame has finished rendering in this context,  the transferToImageBitmap() method can be called to save the most recent rendered image. This method returns an ImageBitmap object, which can be used in a variety of Web APIs and also in a second canvas without creating a transfer copy.
[[
 
Web workers and Offscreen Canvas]]
 
[[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.
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.

Revision as of 03:43, 3 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 the fact that it is specially tuned for better memory safety and concurrency features. Hence, servo seeks to create a highly parallel environment, in which many components are handled by fine-grained and isolated tasks.

Servo makes web-page rendering faster by using parallel layout, styling, web-renders and constellation. Basically, these help to sandbox processes, threads and tasks based on their privilege levels. Sandboxing not only makes way for more responsive web-pages, but it also makes then more secure and robust. Since, when a thread or javascript of a particular section of the webpage fails, it doesn't affects other tabs, browser or eve other elements of the same web-page. So, in a way, Rust lets the browser to "fail better" than other browsers.

CSS3 and HTML5 parser of servo engine have been successfully implemented using Rust, and it successfully passes the acid2 test. Although it is still in early phase of development, it renders web pages significantly more quickly and smoothly, compared to Mozilla's other rendering engines.

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.

About Off Screen Canvas:

The HTML specification defines a <canvas> element that can use a 2d or 3d rendering context. A new specification was recently developed that defines a canvas that can be used without being associated with an in-page canvas element, allowing for more efficient rendering. To use the OffscreenCanvas API, we have used a RenderingContext that has been obtained from an OffscreenCanvas object to generate new frames. Once a new frame has finished rendering in this context, the transferToImageBitmap() method can be called to save the most recent rendered image. This method returns an ImageBitmap object, which can be used in a variety of Web APIs and also in a second canvas without creating a transfer copy.


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.

Problem Statement:

The following tasks were accomplished in the project:

  • Creating the OffscreenCanvas and OffscreenCanvasRenderingContext2d interfaces with stub method implementations.
  • Implementing the OffscreenCanvas Constructor [1] that creates a new canvas.
  • The OffscreenCanvas Constructor has essentially 2 properties: OffscreenCanvas.width and OffscreenCanvas.height, which represents the width and height of the canvas respectively.
  • The constructor also has the method OffscreenCanvas.getContext().

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.

Code Flow

  • First, IDL files namely OffScreenCanvas.webidl and OffScreenCanvasRenderingContext2D.webidl were added at the locations components/script/dom/webidls/OffScreenCanvas.webidl and components/script/dom/webidls/OffScreenCanvasRenderingContext2D.webidl respectively.