Expertiza_Wiki - User contributions [en]

File:Report001.PNG

2014-12-04T04:45:13Z

Apjoshi: uploaded a new version of "File:Report001.PNG"

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:24:18Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:M1455newcrop.png]]</center>

As you can see the image is not being rendered as intended. It is suspected to be a bud in the rust image library developed by the PistonDevelopers. We have been asked by servo representatives to raise an issue with the developers of the rust image library.

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

File:M1455newcrop.png

2014-12-04T04:21:34Z

Apjoshi:

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:21:22Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:M1455newcrop.png]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:14:28Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:M1455new.png]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:14:12Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:M1455_new.png]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:13:12Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:New.png]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:12:03Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:New.PNG]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:11:12Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:new.PNG]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:10:21Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
<center>[[File:new_lena_jpg.PNG]]</center>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

File:New lena jpg.png

2014-12-04T04:09:48Z

Apjoshi:

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:09:29Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library: 
[[File:new_lena_jpg]]

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:08:59Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>
Below you can see the image being rendered after importing the new rust image library:
[[File:new_lena_jpg]]

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T04:04:45Z

Apjoshi:

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== Video ==
A walkthrough of our entire project is available on this link: [https://www.youtube.com/watch?v=rq8MvpR1JyI Final Project Walkthrough]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:16:08Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

<center>[[File:Report001.PNG]]</center>

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:15:40Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

[[File:Report001.PNG]]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

File:Report001.PNG

2014-12-04T03:14:41Z

Apjoshi: uploaded a new version of "File:Report001.PNG"

File:Report001.PNG

2014-12-04T03:13:41Z

Apjoshi:

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:11:10Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

[[File:Report001.png]]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:10:43Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

[[File:Report1.png]]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:10:18Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5. Our test cases include reporting the timing differences for loading PNGs and non-PNG images. The following report has been made with respect to the same:

[[File:Report.png]]

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T03:08:44Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.http://optipng.sourceforge.net/pngtech/img/lena.png</pre>

5.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T02:46:47Z

Apjoshi: /* Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run http://simple.wikipedia.org/wiki/Main_Page</pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.</pre>

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T02:40:29Z

Apjoshi: /* Proposed Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes printing the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command which gives the decoding time for the image passed as an argument:
<pre>./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html</pre>

3. After replacing the rust-freetype library by the freetype-rs library, we have tested that it works as expected by passing a webpage url and checking that the text renders correctly.
<pre>./mach run https://www. </pre>

4. After replacing the rust-stb-image and stb-image libraries with rust-image library and rewriting the load_from_memory function, we tested the the imports worked as expected by passing in different formats of images as urls and rendering them.
<pre> ./mach run https://www.</pre>

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T02:30:39Z

Apjoshi: /* Proposed Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes priniting the decoding time for various image formates and has been included in the wiki: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step]

2. The profiler is meant to capture the image decoding time take by the load_from_memory function. The profiler is run using the following command:
<pre> </pre>

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T02:28:58Z

Apjoshi: /* Proposed Test Cases */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.
In order to import the new library we modified the following files files in the repository [https://github.com/ankit3005/servo]:
*Cargo.toml
*components/net/lib.rs
*components/net/image_cache_task.rs
*components/net/image/base.rs
*components/net/image/holder.rs
*components/gfx/render_context.rs
*components/gfx/lib.rs
*components/gfx/Cargo.toml
*components/gfx/display_list/mod.rs
*components/layout/display_list_builder.rs
*components/layout/lib.rs

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.
Once the new image library was imported , passed in several test images to record the decoding timing for different images.
The timing was compared with the decoding time for images by passing in the same images to the servo build containing the C image library.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

1. The initial step test case includes priniting the decoding time for various image formates and has been included in the wiki:

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

File:Profiler.png

2014-12-04T01:32:56Z

Apjoshi: uploaded a new version of "File:Profiler.png"

File:Profiler.png

2014-12-04T01:31:26Z

Apjoshi: uploaded a new version of "File:Profiler.png"

File:Profiler.png

2014-12-04T01:23:37Z

Apjoshi:

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:22:46Z

Apjoshi:

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>
[[File:Profiler.png]]

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:17:36Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

2. Imported the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Imported the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.

4. Reported the timing differences for loading PNGs and non-PNGs on the same benchmarks.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:15:15Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

2. Import the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Import the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:15:00Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

2. Import the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

3. Import the rust-image library to replace the rust-stb-image and stb-image libraries and rewrite the load_from_memory function which uses these libraries.[5]

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:14:05Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

2. Import the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check the changes on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:13:25Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

1. Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

2. Import the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check this accepted pull on [https://github.com/PistonDevelopers/freetype-rs/pull/70 pull request] for more info.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:11:53Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

# Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

# Import the freetype-rs library to replace rust-freetype in Servo.
We replaced the currently used rust-freetype library with the freetype-rs library. To enable proper functioning of servo after importing the new library, following files were modified in the repository [https://github.com/PistonDevelopers/freetype-rs]:
*Cargo.toml
*src/ffi.rs
*src/lib.rs
*src/lib.rs
*src/library.rs
*src/tt_os2.rs
These changes were committed and have been pulled by PistonDevelopers. Check this accepted pull on [https://github.com/PistonDevelopers/freetype-rs/pull/70] for more info.

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T01:03:55Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

# Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs
To invoke the profiler, we added a category under which to group the timings and passed a TimeProfilerChan (ie. a channel for communicating with the profiler task) to the ImageCacheTask::new method. On successfully building and running servo, we get the following image timings by profiler on the console:
<pre> ./mach run -p 1 https://optipng.sourceforge.net/pngtech/img/lena.html </pre>

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T00:56:28Z

Apjoshi: /* Implementation of the Final Requirements */

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

# Add Image Decoding time to the Profiler
To profile the time required by the load_from_memory to decode an image, we make a call to the profiler which outputs the time taken to decode on the console. To enable the profiler to do so, the following files were changed:
*image_cache_task.rs
*lib.rs
*time.rs

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-12-04T00:53:37Z

Apjoshi:

This wiki page contains design details for the project on [https://github.com/servo/servo/wiki/Replace-C-libraries-student-project Evaluate replacing C libraries with modern Rust equivalents] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Background Information <ref>http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa</ref> ==

===Rust===
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It is designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.
Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

===Servo===
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs.
Servo builds on top of Rust to provide a secure and reliable foundation. Rust’s lightweight task mechanism promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. Servo is not designed to create a full browser but is rather focused on creating a reliable and fast browser engine.

== Introduction ==
Servo currently depends on a lot of C libraries for image decoding. We wish to evaluate switching some of these to new Rust libraries. This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

====Setup of Development Environment====
Servo is currently developed on 64bit OS X and 64bit Linux.

The steps needed to build on a Debian based 64 bit Linux machine are included below. The instructions for other platforms are available [https://github.com/servo/servo#prerequisites here].

* Install the prerequisite dependencies
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

* Clone and build servo repository
<pre>
git clone https://www.github.com/servo/servo
cd servo
./mach build
./mach run tests/html/about-mozilla.html
</pre>

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

The scope of our project is limited to changing the libraries used in the image decoding task shown above.

== Requirement analysis ==

Servo currently depends on a lot of C libraries, because Rust equivalents for these libraries did not exist when the project started. Our project is to evaluate switching some of these to new Rust libraries that have since been created. It involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.<ref>https://github.com/servo/servo/wiki/Replace-C-libraries-student-project</ref>

Initial step

Our [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa initial step], implemented for the OSS project involved:
# Building Servo.
# Adding [http://doc.servo.org/util/time/fn.time.html timing code] to the image decoding implementation in the net crate.
# Rebuilding Servo.
# Reporting numbers for different kinds of images (i.e. PNG, JPEG, GIF).

Final Requirements

Our final project requirements are to:
* Build Servo and add code that reports (via the println! macro) the time required to decode images into displayable pixels.
* Add image decoding timing to the profiler.
* Import the [https://github.com/PistonDevelopers/freetype-rs freetype-rs] library to replace [https://github.com/servo/rust-freetype rust-freetype] in Servo, rewriting necessary code.<ref>https://github.com/servo/servo/issues/3369</ref> For this, we are to use [http://doc.crates.io/ Cargo], the dependency manager for Servo.
* Import the [https://github.com/PistonDevelopers/image rust-image] library to replace the [https://github.com/servo/rust-stb-image rust-stb-image] and [https://github.com/nothings/stb stb-image] libraries and rewrite the <code>load_from_memory</code> function which uses these libraries.<ref>https://github.com/servo/servo/issues/3368</ref>
* Report the timing differences for loading PNGs and non-PNGs on the same benchmarks. For this step, we are to consider profiling the result and optimizing the hotspots in rust-image.

== Implementation of the Final Requirements ==

# Add Image Decoding time to the Profiler

== Data and component design <ref>http://www.rust-ci.org/PistonDevelopers/piston/doc/image/index.html</ref>==

===Data Design===
The system entities that the project deals with is present in the image crate.

The structs and enums used to represent images are as below :

Structures
{| class = "wikitable"
|-
|ImageBuf
|An Image whose pixels are contained within a vector
|-
|Luma
|A type to hold a grayscale pixel
|-
|LumaA
|A type to hold a grayscale pixel with an alpha channel
|-
|MutPixels
|Mutable pixel iterator
|-
|Pixels
|Immutable pixel iterator
|-
|Rgb
|A type to hold an RGB pixel
|-
|Rgba
|A type to hold an RGB pixel with an alpha channel
|-
|SubImage
|A View into another image
|}

Enums
{| class="wikitable"
|-
|ColorType
|An enumeration over supported color types and their bit depths
|-
|DynamicImage
|A Dynamic Image
|-
|FilterType
|Available Sampling Filters
|-
|ImageError
|An enumeration of Image Errors
|-
|ImageFormat
|An enumeration of supported image formats. Not all formats support both encoding and decoding.
|}

===Component Design===

Rust image : It is an image processing library. This crate provides basic imaging processing functions and methods for converting to and from image formats.
All image processing functions provided operate on types that implement the GenericImage trait and return an ImageBuf. The details of other modules and traits included are :

Modules<ref>http://doc.rust-lang.org/guide.html#crates-and-modules</ref>
{| class="wikitable"
|-
|gif
|Decoding of GIF Images
|-
|imageops
|Image Processing Functions
|-
|jpeg
|Decoding and Encoding of JPEG Images
|-
|png
|Decoding and Encoding of PNG Images
|-
|ppm
|Encoding of portable pixmap Images
|-
|webp
|Decoding of Webp Images
|}

Traits<ref>http://rustbyexample.com/trait.html</ref>
{| class="wikitable"
|-
|GenericImage
|A trait for manipulating images.
|-
|ImageDecoder
|The trait that all decoders implement
|-
|MutableRefImage
|A trait for images that allow providing mutable references to pixels.
|-
|Pixel
|A trait that all pixels implement.
|}

Functions
{| class="wikitable"
|-
|load
|Create a new image from a Reader
|-
|load_from_memory
|Create a new image from a byte slice
|-
|open
|Open the image located at the path specified. The image's format is determined from the path's file extension
|}

== Design Principles ==

We are adhering to the following design principles for our implementation:

'''Open-Closed Principle'''<ref>http://en.wikipedia.org/wiki/Open/closed_principle</ref>

Although our task is to evaluate replacing C libraries with Rust libraries, we won't actually be modifying any existing functionality.

'''Interface Segregation Principle'''<ref>http://en.wikipedia.org/wiki/Interface_segregation_principle</ref>

The existing code is currently using the ''rust-freetype'' library for rendering fonts on the browser. We will be replacing this with the ''freetype-rs'' library, which divides the functionality offered by the former into smaller libraries which can be individually implemented instead of calling the entire library.

== Design Pattern==

We have implemented the Adapter Pattern in our Project:

When we updated the image library, the function load_from_memory() in base.rs had to be updated since the return from the updated function accepts a different set of parameters.
We implemented the Adapter pattern as a wrapper function over the new load_from_memory() function which performs the below functions:
1. Based on the file extension generate the ImageFormat Enum.
2. The return of the new function is a Result<DynamicImage>. This needs to be converted into a DynamicImage struct.
<pre>
pub fn load_from_memory(buffer: &[u8],ext: &str) -> Option<DynamicImage> {
if buffer.len() == 0 {
return None;
}
else {
//Retrieve the ImageFormat enum to be passed into the updated function
let image_type: Option< servo_image::ImageFormat > = get_format(ext);
if image_type == None
{
panic!("Image format not supported!");
}
else{
let new_image_type: servo_image::ImageFormat = image_type.unwrap();

//The updated function returns a Result<DynamicImage>
//below code resolves it to be returned by the wrapper function
let result = servo_image::load_from_memory(buffer,new_image_type);
if result.is_ok() {
let v = result.unwrap();
return Some(v);
}
else {
return None;
}
}
}
}

</pre>

==Flowchart describing Project Implementation==
[[File:Flowchart_final_M1455.JPG]]

== UML diagrams ==

===Class Diagram===
[[File:Class_diagram_M1455.JPG]]

== Proposed Test Cases ==

The project does not plan to add new functionality.
The test-cases we propose to run are will ensure that tasks that could be performed with the older C libraries can be executed.

The following test cases are proposed.

# Render different webpages with different fonts. Ensure the text renders correctly
# Render images of different formats (png, jpeg, bmp, gif) of different resolutions. Ensure that the images are rendered correctly.
# Record time taken to render and compare against time taken by the older libraries, for both image and text.

== References ==
<references/>

== See Also ==
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_M1455_asa Initial Step Details]

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-11-11T23:43:09Z

Apjoshi: /* Background Information */

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-11-11T23:42:41Z

Apjoshi: /* See Also */

CSC/ECE 517 Fall 2014/final M1455 yaaa

2014-11-11T23:42:13Z

Apjoshi:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T04:05:29Z

Apjoshi: /* References */

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== Design Pattern ==
Factory Pattern: Using Factory Patterns, the class hierarchy or prototypes can be changed or refactored without needing to change code that uses them – they abstract from the class hierarchy or prototypes. Since we will be replacing the existing C libraries with equivalent rust libraries, factory pattern is applicable here.

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/ 
http://www.oodesign.com/factory-pattern.html 
[https://www.youtube.com/watch?v=pZ5dwgo5W6E A Walkthrough Video]

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T04:01:42Z

Apjoshi:

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== Design Pattern ==
Factory Pattern: Using Factory Patterns, the class hierarchy or prototypes can be changed or refactored without needing to change code that uses them – they abstract from the class hierarchy or prototypes. Since we will be replacing the existing C libraries with equivalent rust libraries, factory pattern is applicable here.

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/ 
[https://www.youtube.com/watch?v=pZ5dwgo5W6E A Walkthrough Video]

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:42:30Z

Apjoshi: /* References */

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/ 
[https://www.youtube.com/watch?v=pZ5dwgo5W6E A Walkthrough Video]

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:42:12Z

Apjoshi: /* References */

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/ 
[https://www.youtube.com/watch?v=pZ5dwgo5W6E A walkthrough Video]

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:38:43Z

Apjoshi: /* EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS */

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:37:58Z

Apjoshi:

[https://docs.google.com/a/ncsu.edu/document/d/18VECpUuVmEaC4Xew4EsIAmOsRKdIeXaTA42tLlNwIho/edit Project Description Page]
== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:34:52Z

Apjoshi: /* Steps of Implementation */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs], we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T03:33:04Z

Apjoshi: /* Introduction to Servo */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS [http://en.wikipedia.org/wiki/Mozilla Mozilla] Project.
It required us to make changes to the [http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] code base.

== Introduction to Rust==
[http://www.rust-lang.org/ Rust] is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
[http://en.wikipedia.org/wiki/Servo_%28layout_engine%29 Servo] is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from [http://en.wikipedia.org/wiki/Git_%28software%29 git] using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along with the dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In image_cache_task.rs , we have a fn decode which calls the load_from_memory fn in [https://github.com/servo/servo/blob/master/components/net/image/base.rs base.rs]. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code around this function call in [https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs image_cache_task.rs] 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line. 
 
Further the tabulated results are reported below: 
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/ 
https://github.com/servo/servo 
https://github.com/rust-lang/rust 
http://doc.rust-lang.org/guide.html 
http://doc.rust-lang.org/ 
https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust 
https://github.com/servo/servo/wiki/Replace-C-libraries-student-project/

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf 
https://blog.mozilla.org/research/ 
http://www.creativebloq.com/mobile/mozilla-provides-servo-browser-engine-insight-4135713