CSC/ECE 517 Fall 2015/M1506-Refactor-GLES2-Implementation

From Expertiza_Wiki
Revision as of 21:37, 3 December 2015 by Asayal (talk | contribs)
Jump to navigation Jump to search

' Refactor GLES2 Student Project with SERVO & RUST '

Servo is a prototype web browser engine written in the RUST language.Servo uses a variety of back-end implementations for drawing graphics depending on the operating system.One of such back-end is only compatible with Android right now, and we want to extend and refactor that back-end to enable on all Linux systems..

Introduction

Servo

ServoServo is an open source prototype web browser layout engine being developed by Mozilla, and it is written in Rust language. The main idea is to create a highly parallel environment, in which different components can be handled by fine grained, isolated tasks. The different components can be rendering, HTML parsing, etc.

Rust

Rust is an open source systems programming language developed by Mozilla. Servo is written in Rust. The main purpose behind it's design is to be thread safe and concurrent. The emphasis is also on speed, safety and control of memory layout.

Project Description

  • The project requirement initially stated that we build and Compile servo. Following are the steps for this:

Servo is built with Cargo, the Rust package manager. Mozilla's Mach tools are used to orchestrate the build and other tasks. 

   git clone https://github.com/servo/servo
   cd servo
   ./mach build --dev
   ./mach run tests/html/about-mozilla.html
  • The next requirement was to build the Rust-layers independently of Servo. For this, we
  • Next, we had to over-ride cargo to use our local copy of Rust-layers, so we had to add a cargo override to it. For this, we created a .cargo folder in our home directory(same place that servo and Rust-layers reside), and added a config file to that folder. The content of that config file is a path to our local Rust-layers.
   paths = [path/to/rust_layers]
  • Next, we had to add a new command line argument in Servo, which would allow selecting the graphics background (GL or ES2). For this, we made the following changes:

- We added a command line option which lets the user enter the option -E or --es2 if the user wants to set ES2 as the graphic back end option. GL is set by default, hence if the user doesn't give any argument, Gl is selected as the graphic back end option. Example is as below 

   ./mach run [url] -E
  • Next, we had to add a flag in Rust-layers. This change was made in the file Rust/src/rendergl.rs in the RenderContext::new function. For this, we did the following change:

- We defined an enum GraphicOption which defined two options GL and ES2 and then based on the boolean value from the servo opts.rs, we set a variable with the respective enum value GL or ES2.

  • Then, we had to use the new command line option to pass the selected graphics back-end option to the Rust-layers context which we created in the previous step. For this we made changes to the compositor.rs in Compositing folder which is how Servo interacts with the Rust layers. The command line option is passed through the initialize_compositing function.
  • Now we need to change the platform implementation in surface.rs and provide a generic implementation to dynamically select between GL & ES2.

Requirement Analysis

Earlier, only OpenGL implementation was supported for Android targets and we would be extending the ES2 implementation to support it for Linux targets. As a part of the final project, we accomplished the following steps:

  • Enable selection of the render api working from the command line, so the user can pick whether to use GL or ES2
  • Modify the necessary files so that the current version of GL or ES2 are returned whenever either of them are selected
  • Make the EGL libs available on Linux for rust-layers to compile rust-egl on Linux build.
  • Separate out the EGLImageNativeSurface implementation from Android and move it to EGL
  • Enable use of EGL or GLX for Linux

Files modified

 Servo/components/utils/opts.rs

added the new command line option to enable user to select the option of GL or ES2 as the rendering backend. The options of GL or ES2 are stored as an enum called RenderApi , such that running the Servo with option --render-api=chosen_option sets the corresponding Api. 

 Servo/ports/glutin/window.rs

gl_version() function is modified in a way that based on what is selected as the RenderApi option by the user, the corresponding version of the Api is set. To talk more in detail,

Files modified

rust-layers/src/platform/surface.rs: providing generic GL implementation that can dynamically select between the 2 interfaces.

Useful libraries

waffle-gl/waffle: A C library for selecting an OpenGL API and window system at runtime.

Design Pattern

The aim is to use ES2 implementation of rust layers for both android and Linux. So we need to use a design pattern that will allow us to extend the current implementation to support Linux targets too and give the user the flexibility to choose between the two implementations for rendering the backend.

We propose to use Decorator pattern. The decorator pattern gives the user the ability to choose between the implementations that are desired, and attach the corresponding implementation to the target dynamically at runtime.


References

1. https://doc.rust-lang.org/stable/book/
2. https://en.wikipedia.org/wiki/Rust_(programming_language)
3. https://en.wikipedia.org/wiki/Servo_(layout_engine)
4. https://github.com/servo/servo/wiki/Refactor-GLES2-student-project
5. http://doc.crates.io/guide.html#overriding-dependencies
6. http://rustbyexample.com/
7. http://javarevisited.blogspot.com/2014/11/strategy-design-pattern-in-java-using-Enum-Example.html

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2015/M1506-Refactor-GLES2-Implementation&oldid=100021"