Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2020 - E2021. Allow reviewers to bid on what to review

2020-04-25T04:58:31Z

Skmuppal: /* Run Bidding Assignment Location Changed */

== '''Problem Statement''' ==
The reviews performed by the students right now are being assigned on a first-come-first-serve basis. The task at hand is to implement a procedure so that the students can bid on the reviews that they would like to review, similar to the procedure of the assignment of the topics. The difference between the two procedures is that the assignment of the topic is a one-one mapping, i.e. a team is assigned to a single topic, whereas the assignment of the reviews is many-many mapping with each review being assigned to different students and each student assigned to different reviews.

=== '''The need for a bidding system for reviews''' ===

The bidding process, when implemented for reviews of projects, will hold several advantages.

1. The users will be able to bid for reviewing the projects that would interest them. This will incentivize them to get a better understanding of the project requirements and provide the necessary feedback in a very informed manner.

2. With the help of color coding, the students will be able to decide on the probability of being assigned to a particular review, that could help them in bidding wisely.

3. It provides the team members working on the project, a very informed feedback on how to enhance their project. Because,the feedback is from people who really are interested on the project.

4. It also helps the instructor in receiving more well-written, useful and meaningful feedback on what projects are more in demand among the students, which would be further useful in crafting the academic projects.

=== '''What needs to be done'''===
The following are the tasks that are to be done-

1. Implement Gale-Shapely version for many-to-many matching situations on a web service as mentioned in the paper [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf].

The Gale-Shapely version for many-to-many matching is an intelligent algorithm that allows users to achieve the review they will need. For example, let us consider a situation where user 'A' wants the review assigned to user 'B' and user 'B' wants the review assigned to user 'A'. Considering that it will motivate the students if they get the project that they would like to review, this mutual exchange between them would be beneficial. This classical problem can be solved using the following algorithm.

[[File:bid.png |center|]]

'''Motivation'''

From a set '''R''' of available review topics, the user u from set '''U''' have to be matched with a pre-configured number of topics r1,r2,r3.....rk. So,the idea is to record the user priority and time-stamp at which r is bid. This information can then be used to change the color of the review in real time, which could further let the users know that their bid for this particular bis cannot be given a top priority. Once the bidding timeline is past, the recorded information for each bis is then fed to the algorithm, which would then match user u to review r1,r2,r3...rk.

'''How should the algorithm match students '''S''' to the Review set '''R ''' ?

The algorithm has to initially append additional reviews randomly in case, the user did not bid for the required number of reviews. Then based on the input data of the list for each student, which contains the topic,time-stamp and priority it has to allot the review to a student with earliest time stamp and highest priority.

'''Algorithm Steps'''

1) Let the user bid, these bids will have time-stamps and priority(determined by the color of the bid at that time stamp).

2) There will be cycles links of length 1 between the person who owns every review currently,which generates a directed acyclic graph.

3) We the will need to break all the cycles in the graph and assign the reviews to which the user is pointing at. The top is represent as [ TOP(i) ]

4) We can repeat this order until we have exhausted our preference list where all the assigned reviews are constantly deleted.

5) We will repeat this process for all the slots of the bidding until the users gets all these review slots filled, making it many to many.

[[File:bid1.png |center|]]

From the diagram we can see that the three users are represented as u1, u2, u3 and the the three reviews are r1,r2,r3.

In '''phase 1''' : All users want the review 1 so all of them point to r1 and we see r1 is owned by u1 and r2 is owned by u2 and r3 by u3.

In '''phase 2''' : u1 is assigned r1 and now u2 points to r3 which is now its highest priority because r1 is removed and similarly u3 points to r2.

In '''phase 3''' : r2 is assigned to u3 and and r3 is assigned to u2, thus satisfying all.

2. Add the front end code to allow the bidding on topics and call the appropriate web services from the lottery controller. This is similar to the already implemented bidding process on topics [https://github.com/expertiza/expertiza/pull/778/commits].

'''Flow chart for this us functionality would involve :'''

[[File:flow.png |center|]]

=== '''Previous Work''' ===
The latest implementation of the problem was E1986 [https://github.com/expertiza/expertiza/pull/1629][https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor].

We can see that they have figured out the issues with the bidding assignement being one to one and not many to one and have succesfully used the Gale-Shapely version for many-to-many matching algorithm to solve the issues. They have also fixed a few problems with the UI that were being faced with the buttons and writing proper test cases.

From the previous implementations we can see that the following files were modified in order to get the required implementation they have modified the following files :

'''Modified Files'''

routes.rb

app/views/student_task/view.html.erb

app/views/assignments/edit.html.erb

app/controllers/student_task_controller

'''New Files'''

app/controllers/review_bidding.rb

app/models/review_bidding_controller.rb

app/views/sign_up_sheet/review_bid.html.erb

Source Code for the Web Service

=== '''Problems found in previous work''' ===
The problems in the previous work were given-

1. The link to the run bidding assignment is on the Review Strategy tab instead of the actions associated with an assignment like the topic assignment. This is an inconsistency in the UI that needs to be remedied.

2. All of the implementation code was put in the controller which is inappropriate for a controller. The code should probably be in the corresponding model file.

3. The tests that they have written are not adequate.

4. It does not allow the Instructor, to decide to whether to allow the bidding for reviews or not.

=='''Improvements Made'''==

==='''Run Bidding Assignment Location Changed'''===
'''Change the location of the running bidding assignment to the appropriate location. This is because it is inconsistent with the UI and will require changes.'''

The part of the code that requires modification is- app/views/assignments/edit.html.erb

[[File:tab.PNG |center|]]

As we can see from the code attached we need to move this code away from the Review Strategy tab.

[[File:ButtonChanged.PNG |center|]]

[[File:intelligent.jpeg |center|]]

We have also added a checkbox to check if the algorithm is run or not based on the value of the checkbox that is ticked.

[[File:ff1.PNG |center|]]

'''Webservice : '''

The previous team had not set up the web service as internet-facing. It was only working on their local system because they were facing issues with the flask framework setup. We have successfully setup up the web service call and made it internet facing.

The code can be found at the following repository: https://github.com/akashsrikanth2310/expertiza-topic-bidding which is hosted using Heroku and can be accessed from the expertiza application.

Various refactors on the code were also performed the changes are shown below.

==='''Refactoring to maintain DRY'''===
Write the code where it is suitable, following the DRY principles.

The first file where we want to apply the principle to is the: app/controllers/review_bidding_controller.rb

The code is shown below:

'''Previous Implementation :'''
[[File:r1.PNG |center|]]

From this, we can see the entire method can be moved to the model to reduce the stress on the model. The assignment participant code is moved to the controller thereby making it easier to perform separations of the model, view, and controller. Also in the below code attached we try to move the entire assignment_bidding_data to the model as well.

'''Previous Implementation :'''
[[File:a1.PNG]]

The implemented changes by moving the code to the model are shown in the code attached below. WE can see that both the method has been successfully moved to the model and thereby reducing the stress on the controller. The assignment_reviewers function is the function that will return the participant ids of all the reviewers who have a topic that is assigned to them. It will run a for loop to get the details and return an array of reviewers with assigned topics.

'''Current Implementation :'''
[[File:s1.PNG |center|]]

The other function that we choose to move to controller hence to make sure the computations are performed only the model side is first the reviewer_bidding_data

'''Previous Implementation :'''
[[File:a2.PNG |center|]]

The function reviewer_self topic shown below was also moved.

'''Previous Implementation :'''
[[File:a3.PNG |center|]]

The new code that is attached to the model is shown below
The reviewer_bidding_data file creates a hash of all values tat is required for a bidding value its has will hold keys and values for {'priority' => [], 'time' => => [] , 'tid' => [] , 'otid' => self_topic} it runs through the bids and get the required cols to add to the hash.

'''Current Implementation :'''
[[File:s2.PNG |center|]]

The reviwer_self_topic is used to get the necessary self topic that is been assigned to the reviewer and the values will be returned based on what is been assigned.

'''Current Implementation :'''
[[File:s3.PNG |center|]]

In the same file, we notice the method: get_quartiles(topic_id) which assigns colors to the topics based on how much in demand they are.

[[File:quar.PNG |center|]]

We would like to again reduce the assignment statements and move the entire if structure to the model to return the colors reducing stress on the controller.

==='''Writing Suitable Tests'''===
Write suitable tests to ensure that the implementation is working.

The previous implementation gave their try on implementing the required test but all of them are commented out. So, they are required to be redone during this implementation.

'''Previous Implementation'''
[[File:test.PNG |center|]]

'''Previous Implementation'''
We can see that the previous implementation has all the tests removed, the changed test cases are shown in the testing subtopic.
[[File:test1.PNG |center|]]

'''Current Implementation'''
The current testing implementation has been shown below, in the '''Plan for Testing''' section.

== '''Plan for Testing'''==

=== '''Test Cases'''===

'''Manual Testing :'''
There are a few cases that need to be tested.

1. The first case would be to test for the scenario, where no reviewer bids i.e. no one has given a preference of any sort. Then the bidding algorithm should assign reviews randomly.

2. The other case would be when all reviewers have selected a different project as their preference, at different times. This is an ideal scenario given that the reviewer cannot bid for his own project.

3. The other scenario would be when everyone selects the same project at the same or different times and does not provide any other choice or preference. This can be the scenario if one project is relatively interesting or easy to review in comparison to the others in the roster.

4. Another scenario would be if some projects haven't been selected at all for reviewing, this case arises if the particular project may require additional effort on the part of the reviewing to successfully complete the review.

5. A usual scenario is that the reviewers select all or most of the projects, and each project is on at least one reviewer's biding list.

Automatic testing :

Few tests have been written for both the controller and the models :

the file we can see that tests were written for the controller that checks if the web-service call is fine. The Call to the webservice is made and check if the response code returned is fine. It checks if the right status code is returned on processing. Also it eventually checks for the json data being returned succesffuly.

[[File:e1.PNG |center|]]

The screenshot of the passed tests are shown below :

[[File:ss.jpeg |center|]]

The other tests that are written are for the model. It check if the model has validations of the priority, participant_id and topic_id to be the right values as set in the database also it checks if the values returned from participant_id and topic_id are integers.

[[File:e2.PNG |center|]]

The other tests written checks if the assignment id is assigned right and if its an integer. It also checks if the assignment_reviewers returns an array and if the assignment_bidding_data will return a hash value in return. The review_bidding_data is also checked for the right hash values.

[[File:e3.PNG |center|]]

The screenshot of the passed tests are shown below :

[[File:Chill1.PNG |center|]]

In all of the above cases, all the projects have to be assigned to at least one reviewer so that every project has been peer-reviewed.

== '''References''' ==
[1] [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf School Choice: A Mechanism Design Approach] by Atila Abdulkadiroğlu and Tayfun Sönmez.

[2] [https://github.com/expertiza/expertiza/pull/778/commits Bidding Interface Implementation].

[3] [https://github.com/expertiza/expertiza/pull/1629 E1986 Pull Request].

[4] [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor E1986 Wiki page].

File:Intelligent.jpeg

2020-04-25T04:55:25Z

Skmuppal: Skmuppal uploaded a new version of File:Intelligent.jpeg

File:Intelligent.jpeg

2020-04-25T04:47:54Z

Skmuppal:

File:Checkbox.png

2020-04-24T22:39:32Z

Skmuppal: Skmuppal uploaded a new version of File:Checkbox.png

File:Inconsitency.png

2020-04-24T22:19:03Z

Skmuppal:

CSC/ECE 517 Spring 2020 - E2021. Allow reviewers to bid on what to review

2020-04-24T22:14:04Z

Skmuppal:

== '''Problem Statement''' ==
The reviews performed by the students right now are being assigned on a first-come-first-serve basis. The task at hand is to implement a procedure so that the students can bid on the reviews that they would like to review, similar to the procedure of the assignment of the topics. The difference between the two procedures is that the assignment of the topic is a one-one mapping, i.e. a team is assigned to a single topic, whereas the assignment of the reviews is many-many mapping with each review being assigned to different students and each student assigned to different reviews.

=== '''The need for a bidding system for reviews''' ===

The bidding process, when implemented for reviews of projects, will hold several advantages.

1. The users will be able to bid for reviewing the projects that would interest them. This will incentivize them to get a better understanding of the project requirements and provide the necessary feedback in a very informed manner.

2. With the help of color coding, the students will be able to decide on the probability of being assigned to a particular review, that could help them in bidding wisely.

3. It provides the team members working on the project, a very informed feedback on how to enhance their project. Because,the feedback is from people who really are interested on the project.

4. It also helps the instructor in receiving more well-written, useful and meaningful feedback on what projects are more in demand among the students, which would be further useful in crafting the academic projects.

=== '''What needs to be done'''===
The following are the tasks that are to be done-

1. Implement Gale-Shapely version for many-to-many matching situations on a web service as mentioned in the paper [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf].

The Gale-Shapely version for many-to-many matching is an intelligent algorithm that allows users to achieve the review they will need. For example, let us consider a situation where user 'A' wants the review assigned to user 'B' and user 'B' wants the review assigned to user 'A'. Considering that it will motivate the students if they get the project that they would like to review, this mutual exchange between them would be beneficial. This classical problem can be solved using the following algorithm.

[[File:bid.png |center|]]

'''Motivation'''

From a set '''R''' of available review topics, the user u from set '''U''' have to be matched with a pre-configured number of topics r1,r2,r3.....rk. So,the idea is to record the user priority and time-stamp at which r is bid. This information can then be used to change the color of the review in real time, which could further let the users know that their bid for this particular bis cannot be given a top priority. Once the bidding timeline is past, the recorded information for each bis is then fed to the algorithm, which would then match user u to review r1,r2,r3...rk.

'''How should the algorithm match students '''S''' to the Review set '''R ''' ?

The algorithm has to initially append additional reviews randomly in case, the user did not bid for the required number of reviews. Then based on the input data of the list for each student, which contains the topic,time-stamp and priority it has to allot the review to a student with earliest time stamp and highest priority.

'''Algorithm Steps'''

1) Let the user bid, these bids will have time-stamps and priority(determined by the color of the bid at that time stamp).

2) There will be cycles links of length 1 between the person who owns every review currently,which generates a directed acyclic graph.

3) We the will need to break all the cycles in the graph and assign the reviews to which the user is pointing at. The top is represent as [ TOP(i) ]

4) We can repeat this order until we have exhausted our preference list where all the assigned reviews are constantly deleted.

5) We will repeat this process for all the slots of the bidding until the users gets all these review slots filled, making it many to many.

[[File:bid1.png |center|]]

From the diagram we can see that the three users are represented as u1, u2, u3 and the the three reviews are r1,r2,r3.

In '''phase 1''' : All users want the review 1 so all of them point to r1 and we see r1 is owned by u1 and r2 is owned by u2 and r3 by u3.

In '''phase 2''' : u1 is assigned r1 and now u2 points to r3 which is now its highest priority because r1 is removed and similarly u3 points to r2.

In '''phase 3''' : r2 is assigned to u3 and and r3 is assigned to u2, thus satisfying all.

2. Add the front end code to allow the bidding on topics and call the appropriate web services from the lottery controller. This is similar to the already implemented bidding process on topics [https://github.com/expertiza/expertiza/pull/778/commits].

'''Flow chart for this us functionality would involve :'''

[[File:flow.png |center|]]

=== '''Previous Work''' ===
The latest implementation of the problem was E1986 [https://github.com/expertiza/expertiza/pull/1629][https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor].

We can see that they have figured out the issues with the bidding assignement being one to one and not many to one and have succesfully used the Gale-Shapely version for many-to-many matching algorithm to solve the issues. They have also fixed a few problems with the UI that were being faced with the buttons and writing proper test cases.

From the previous implementations we can see that the following files were modified in order to get the required implementation they have modified the following files :

'''Modified Files'''

routes.rb

app/views/student_task/view.html.erb

app/views/assignments/edit.html.erb

app/controllers/student_task_controller

'''New Files'''

app/controllers/review_bidding.rb

app/models/review_bidding_controller.rb

app/views/sign_up_sheet/review_bid.html.erb

Source Code for the Web Service

=== '''Problems found in previous work''' ===
The problems in the previous work were given-

1. The link to the run bidding assignment is on the Review Strategy tab instead of the actions associated with an assignment like the topic assignment. This is an inconsistency in the UI that needs to be remedied.

2. All of the implementation code was put in the controller which is inappropriate for a controller. The code should probably be in the corresponding model file.

3. The tests that they have written are not adequate.

4. It does not allow the Instructor, to decide to whether allow the bidding for reviews or not.

=== '''Suggested Improvements'''===

1. Change the location of the running bidding assignment to the appropriate location. This is because it is inconsistent with the UI and will require changes.

The part of the code that requires modification is- app/views/assignments/edit.html.erb

[[File:tab.PNG |center|]]

As we can see from the code attached we need to move this code away from the Review Strategy tab.

[[File:Locationchange.PNG |center|]]

2. Write the code where it is suitable, following the DRY principles.

The first file where we want to apply the principle to is the: app/controllers/review_bidding_controller.rb

The code is shown below:

[[File:rbid.PNG |center|]]

From this, we can see there are a lot of assignment operations taking place which could be toned down a bit by choosing the exact variable required for the class. Also, the loop that runs in the controller appending values to signed_up_topics = [] should be moved to the model class and reduce the stress on the controller. Also the code @bids = team_id.nil? ? [] : ReviewBid.where(participant_id:@participant,assignment_id:@assignment.id).order(:priority) in pretty deep coupled and could be broken down and moved to the model.

In the same file, we notice the method: get_quartiles(topic_id) which assigns colors to the topics based on how much in demand they are.

[[File:quar.PNG |center|]]

We would like to again reduce the assignment statements and move the entire if structure to the model to return the colors reducing stress on the controller.

The next function in this file is set_priority, where we want to rewrite the if structure because we fell its too long and has a very convoluted structure to it. The code shown below clearly shows the multiple nested if structs that we want to remove. Having multiple if structs could fail the code at unexpected edge points.

[[File:set.PNG |center|]]

3. Write suitable tests to ensure that the implementation is working.

The previous implementation gave their try on implementing the required test but all of them are commented out. So, they are required to be redone during this implementation.

[[File:test.PNG |center|]]

[[File:test1.PNG |center|]]

4. Make sure the reviewer cannot bid for his own project.

This was done in the previous implementation in both using the set_priority and review_bid methods, but the structure is pretty complex to these and we would like to work on reducing the complexity of these functions and also moving parts of these codes to the model.

=== '''Plan for Testing'''===

As of now, and as far as we understood the feature.

=== '''Test Cases'''===

There are a few cases that need to be tested.

1. The first case would be to test for the scenario, where no reviewer bids i.e. no one has given a preference of any sort. Then the bidding algorithm should assign reviews randomly.

2. The other case would be when all reviewers have selected a different project as their preference, at different times. This is an ideal scenario given that the reviewer cannot bid for his own project.

3. The other scenario would be when everyone selects the same project at the same or different times and does not provide any other choice or preference. This can be the scenario if one project is relatively interesting or easy to review in comparison to the others in the roster.

4. Another scenario would be if some projects haven't been selected at all for reviewing, this case arises if the particular project may require additional effort on the part of the reviewing to successfully complete the review.

5. A usual scenario is that the reviewers select all or most of the projects, and each project is on at least one reviewer's biding list.

In all of the above cases, all the projects have to be assigned to at least one reviewer so that every project has been peer-reviewed.

== '''References''' ==
[1] [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf School Choice: A Mechanism Design Approach] by Atila Abdulkadiroğlu and Tayfun Sönmez.

[2] [https://github.com/expertiza/expertiza/pull/778/commits Bidding Interface Implementation].

[3] [https://github.com/expertiza/expertiza/pull/1629 E1986 Pull Request].

[4] [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor E1986 Wiki page].

File:Asset location change.png

2020-04-24T22:11:24Z

Skmuppal: Skmuppal uploaded a new version of File:Asset location change.png

File:Asset location change.png

2020-04-24T22:02:15Z

Skmuppal: Skmuppal uploaded a new version of File:Asset location change.png

CSC/ECE 517 Spring 2020 - E2021. Allow reviewers to bid on what to review

2020-04-24T21:59:26Z

Skmuppal:

== '''Problem Statement''' ==
The reviews performed by the students right now are being assigned on a first-come-first-serve basis. The task at hand is to implement a procedure so that the students can bid on the reviews that they would like to review, similar to the procedure of the assignment of the topics. The difference between the two procedures is that the assignment of the topic is a one-one mapping, i.e. a team is assigned to a single topic, whereas the assignment of the reviews is many-many mapping with each review being assigned to different students and each student assigned to different reviews.

=== '''The need for a bidding system for reviews''' ===

The bidding process, when implemented for reviews of projects, will hold several advantages.

1. The users will be able to bid for reviewing the projects that would interest them. This will incentivize them to get a better understanding of the project requirements and provide the necessary feedback in a very informed manner.

2. With the help of color coding, the students will be able to decide on the probability of being assigned to a particular review, that could help them in bidding wisely.

3. It provides the team members working on the project, a very informed feedback on how to enhance their project. Because,the feedback is from people who really are interested on the project.

4. It also helps the instructor in receiving more well-written, useful and meaningful feedback on what projects are more in demand among the students, which would be further useful in crafting the academic projects.

=== '''What needs to be done'''===
The following are the tasks that are to be done-

1. Implement Gale-Shapely version for many-to-many matching situations on a web service as mentioned in the paper [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf].

The Gale-Shapely version for many-to-many matching is an intelligent algorithm that allows users to achieve the review they will need. For example, let us consider a situation where user 'A' wants the review assigned to user 'B' and user 'B' wants the review assigned to user 'A'. Considering that it will motivate the students if they get the project that they would like to review, this mutual exchange between them would be beneficial. This classical problem can be solved using the following algorithm.

[[File:bid.png |center|]]

'''Motivation'''

From a set '''R''' of available review topics, the user u from set '''U''' have to be matched with a pre-configured number of topics r1,r2,r3.....rk. So,the idea is to record the user priority and time-stamp at which r is bid. This information can then be used to change the color of the review in real time, which could further let the users know that their bid for this particular bis cannot be given a top priority. Once the bidding timeline is past, the recorded information for each bis is then fed to the algorithm, which would then match user u to review r1,r2,r3...rk.

'''How should the algorithm match students '''S''' to the Review set '''R ''' ?

The algorithm has to initially append additional reviews randomly in case, the user did not bid for the required number of reviews. Then based on the input data of the list for each student, which contains the topic,time-stamp and priority it has to allot the review to a student with earliest time stamp and highest priority.

'''Algorithm Steps'''

1) Let the user bid, these bids will have time-stamps and priority(determined by the color of the bid at that time stamp).

2) There will be cycles links of length 1 between the person who owns every review currently,which generates a directed acyclic graph.

3) We the will need to break all the cycles in the graph and assign the reviews to which the user is pointing at. The top is represent as [ TOP(i) ]

4) We can repeat this order until we have exhausted our preference list where all the assigned reviews are constantly deleted.

5) We will repeat this process for all the slots of the bidding until the users gets all these review slots filled, making it many to many.

[[File:bid1.png |center|]]

From the diagram we can see that the three users are represented as u1, u2, u3 and the the three reviews are r1,r2,r3.

In '''phase 1''' : All users want the review 1 so all of them point to r1 and we see r1 is owned by u1 and r2 is owned by u2 and r3 by u3.

In '''phase 2''' : u1 is assigned r1 and now u2 points to r3 which is now its highest priority because r1 is removed and similarly u3 points to r2.

In '''phase 3''' : r2 is assigned to u3 and and r3 is assigned to u2, thus satisfying all.

2. Add the front end code to allow the bidding on topics and call the appropriate web services from the lottery controller. This is similar to the already implemented bidding process on topics [https://github.com/expertiza/expertiza/pull/778/commits].

'''Flow chart for this us functionality would involve :'''

[[File:flow.png |center|]]

=== '''Previous Work''' ===
The latest implementation of the problem was E1986 [https://github.com/expertiza/expertiza/pull/1629][https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor].

We can see that they have figured out the issues with the bidding assignement being one to one and not many to one and have succesfully used the Gale-Shapely version for many-to-many matching algorithm to solve the issues. They have also fixed a few problems with the UI that were being faced with the buttons and writing proper test cases.

From the previous implementations we can see that the following files were modified in order to get the required implementation they have modified the following files :

'''Modified Files'''

routes.rb

app/views/student_task/view.html.erb

app/views/assignments/edit.html.erb

app/controllers/student_task_controller

'''New Files'''

app/controllers/review_bidding.rb

app/models/review_bidding_controller.rb

app/views/sign_up_sheet/review_bid.html.erb

Source Code for the Web Service

=== '''Problems found in previous work''' ===
The problems in the previous work were given-

1. The link to the run bidding assignment is on the Review Strategy tab instead of the actions associated with an assignment like the topic assignment. This is an inconsistency in the UI that needs to be remedied.

2. All of the implementation code was put in the controller which is inappropriate for a controller. The code should probably be in the corresponding model file.

3. The tests that they have written are not adequate.

4. It does not allow the Instructor, to decide to whether allow the bidding for reviews or not.

=== '''Suggested Improvements'''===

1. Change the location of the running bidding assignment to the appropriate location. This is because it is inconsistent with the UI and will require changes.

The part of the code that requires modification is- app/views/assignments/edit.html.erb

[[File:tab.PNG |center|]]

As we can see from the code attached we need to move this code away from the Review Strategy tab.

[[File:Locationchange.png]]

2. Write the code where it is suitable, following the DRY principles.

The first file where we want to apply the principle to is the: app/controllers/review_bidding_controller.rb

The code is shown below:

[[File:rbid.PNG |center|]]

From this, we can see there are a lot of assignment operations taking place which could be toned down a bit by choosing the exact variable required for the class. Also, the loop that runs in the controller appending values to signed_up_topics = [] should be moved to the model class and reduce the stress on the controller. Also the code @bids = team_id.nil? ? [] : ReviewBid.where(participant_id:@participant,assignment_id:@assignment.id).order(:priority) in pretty deep coupled and could be broken down and moved to the model.

In the same file, we notice the method: get_quartiles(topic_id) which assigns colors to the topics based on how much in demand they are.

[[File:quar.PNG |center|]]

We would like to again reduce the assignment statements and move the entire if structure to the model to return the colors reducing stress on the controller.

The next function in this file is set_priority, where we want to rewrite the if structure because we fell its too long and has a very convoluted structure to it. The code shown below clearly shows the multiple nested if structs that we want to remove. Having multiple if structs could fail the code at unexpected edge points.

[[File:set.PNG |center|]]

3. Write suitable tests to ensure that the implementation is working.

The previous implementation gave their try on implementing the required test but all of them are commented out. So, they are required to be redone during this implementation.

[[File:test.PNG |center|]]

[[File:test1.PNG |center|]]

4. Make sure the reviewer cannot bid for his own project.

This was done in the previous implementation in both using the set_priority and review_bid methods, but the structure is pretty complex to these and we would like to work on reducing the complexity of these functions and also moving parts of these codes to the model.

=== '''Plan for Testing'''===

As of now, and as far as we understood the feature.

=== '''Test Cases'''===

There are a few cases that need to be tested.

1. The first case would be to test for the scenario, where no reviewer bids i.e. no one has given a preference of any sort. Then the bidding algorithm should assign reviews randomly.

2. The other case would be when all reviewers have selected a different project as their preference, at different times. This is an ideal scenario given that the reviewer cannot bid for his own project.

3. The other scenario would be when everyone selects the same project at the same or different times and does not provide any other choice or preference. This can be the scenario if one project is relatively interesting or easy to review in comparison to the others in the roster.

4. Another scenario would be if some projects haven't been selected at all for reviewing, this case arises if the particular project may require additional effort on the part of the reviewing to successfully complete the review.

5. A usual scenario is that the reviewers select all or most of the projects, and each project is on at least one reviewer's biding list.

In all of the above cases, all the projects have to be assigned to at least one reviewer so that every project has been peer-reviewed.

== '''References''' ==
[1] [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf School Choice: A Mechanism Design Approach] by Atila Abdulkadiroğlu and Tayfun Sönmez.

[2] [https://github.com/expertiza/expertiza/pull/778/commits Bidding Interface Implementation].

[3] [https://github.com/expertiza/expertiza/pull/1629 E1986 Pull Request].

[4] [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor E1986 Wiki page].

File:Asset location change.png

2020-04-24T21:56:38Z

Skmuppal:

CSC/ECE 517 Spring 2020 - E2021. Allow reviewers to bid on what to review

2020-04-14T00:35:31Z

Skmuppal: /* Plan for Testing */

== '''Motivation''' ==

Currently, the projects to review are assigned to the reviewers on a first come first serve basis. This policy does not let the reviewers investigate and learn from the projects they are specifically interested in. Therefore, the idea here is to let the students decide on what projects they wish to review in a fair manner by placing a bidding policy.

== '''Problem Statement''' ==
The reviews performed by the students right now are being assigned on a first-come-first-serve basis. The task at hand is to implement a procedure so that the students can bid on the reviews that they would like to review, similar to the procedure of the assignment of the topics. The difference between the two procedures is that the assignment of the topic is a one-one mapping, i.e. a team is assigned to a single topic, whereas the assignment of the reviews is many-many mapping with each review being assigned to different students and each student assigned to different reviews.

=== '''The need for a bidding system for reviews''' ===

The bidding process, when implemented for reviews of projects, will hold several advantages.

1. The users will be able to bid for reviews that interest them. This will incentivize them to get a better understanding of the project requirements and provide the necessary feedback in an informed manner.

2. Bidding provides the users receiving feedback a very informed report on how to enhance their project. This will help them get better results for their respective projects.

3. The bidding also gives an advantage to the instructor because the instructor will now be able to receive more well-written, useful and meaningful feedback that will be more useful in their academic projects.

=== '''What needs to be done'''===
The following are the tasks that are to be done-

1. Implement top trading cycles on a web service as mentioned in the paper [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf].

The top trading cycles is an intelligent algorithm that allows users to achieve the review they will need. For example, let us consider a situation where user 'A' wants the review assigned to user 'B' and user 'B' wants the review assigned to user 'A'. Considering that it will motivate the students if they get the project that they would like to review, this mutual exchange between them would be beneficial. It can be solved using the top trading cycles algorithm.

[[File:bid.png |center|]]

'''Algorithm Steps'''

1) Let the user bid, these bids will point to the reviews they are requesting for in the graph.

2) There will be cycles links of length 1 between the person who owns ever review currently, a directed acyclic graph.

3) We will need to break all the cycles in the graph and assign the reviews to which the user is pointing at. The top is represent as [ TOP(i) ]

4) We can repeat this order until we have exhausted our preference list where all the assigned houses are constantly deleted.

5) we will repeat this bidding process for all slot of the bidding until the user gets all this review slots filled, making it many to many.

[[File:bid1.png |center|]]

From the diagram we can see that the three users are represented as u1, u2, u3 and the the three reviews are r1,r2,r3.

In '''phase 1''' : all users want the review 1 so all of them point to r1 and we see r1 is owned by u1 and r2 is owned by u2 and r3 by u3.

In '''phase 2''' : u1 is assigned r1 and now u2 points to r3 which is now its highest priority because r1 is removed and similarly u3 points to r2.

In '''phase 3''': r2 is assigned to u3 and and r3 is assigned to u2, thus satisfying all.

2. Add the front end code to allow the bidding on topics and call the appropriate web services from the lottery controller. This is similar to the already implemented bidding process on topics [https://github.com/expertiza/expertiza/pull/778/commits].

'''flow chart for this us functionality would involve :'''

[[File:flow.png |center|]]

=== '''Previous Work''' ===
The latest implementation of the problem was E1986 [https://github.com/expertiza/expertiza/pull/1629][https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor].

We can see that they have figured out the issues with the bidding assignement being one to one and not many to one and have succesfully used the Gale-Shapely version for many-to-many matching algorithm to solve the issues. They have also fixed a few problems with the UI that were being faced with the buttons and writing proper test cases.

From the previous implementations we can see that the following files were modified in order to get the required implementation they have modified the following files :

'''Modified Files'''

routes.rb

app/views/student_task/view.html.erb

app/views/assignments/edit.html.erb

app/controllers/student_task_controller

'''New Files'''

app/controllers/review_bidding.rb

app/models/review_bidding_controller.rb

app/views/sign_up_sheet/review_bid.html.erb

Source Code for the Web Service

=== '''Problems found in previous work''' ===
The problems in the previous work were given-

1. The link to the run bidding assignment is on the Review Strategy tab instead of the actions associated with an assignment like the topic assignment. This is an inconsistency in the UI that needs to be remedied.

2. All of the implementation code was put in the controller which is inappropriate for a controller. The code should probably be in the corresponding model file.

3. The tests that they have written are not adequate.

=== '''Suggested Improvements'''===

1. Change the location of the running bidding assignment to the appropriate location. This is because it is inconsistent with the UI and will require changes.

The part of the code that requires modification is : app/views/assignments/edit.html.erb

[[File:tab.PNG |center|]]

As we can see from the code attached we need to move this code away from the Review Strategy tab.

2. Write the code where it is suitable, following the DRY principles.

3. Write suitable tests to ensure that the implementation is working.

4. Make sure the reviewer can't bid for his own project.

=== '''Plan for Testing'''===

As of now, and as far as we understood the feature.

There are a few cases that need to be tested.

1) The first case would be to test for the scenario, where no reviewer bids i.e. no one has given a preference of any sort. Then the bidding algorithm should assign reviews randomly.

2) The other case would be when all reviewers have selected a different project as their preference, at different times. This is an ideal scenario given that the reviewer cannot bid for his own project.

3) The other scenario would be when everyone selects the same project at the same or different times and doesn't provide any other choice or preference. This can be the scenario if one project is relatively interesting or easy to review in comparison to the others in the roster.

4) Another scenario would be if some projects haven't been selected at all for reviewing, this case arises if the particular project may require additional effort on the part of the reviewing to successfully complete the review.

5) A usual scenario is that the reviewers select all or most of the projects, and each project is on at least one reviewers biding list.

In all of the above cases, all the projects have to be assigned to at least one reviewer so that every project has been peer-reviewed.

== '''References''' ==
[1] [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf School Choice: A Mechanism Design Approach] by Atila Abdulkadiroğlu and Tayfun Sönmez.

[2] [https://github.com/expertiza/expertiza/pull/778/commits Bidding Interface Implementation].

[3] [https://github.com/expertiza/expertiza/pull/1629 E1986 Pull Request].

[4] [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor E1986 Wiki page].

CSC/ECE 517 Spring 2020 - E2021. Allow reviewers to bid on what to review

2020-04-14T00:31:29Z

Skmuppal:

== '''Motivation''' ==

Currently, the projects to review are assigned to the reviewers on a first come first serve basis. This policy does not let the reviewers investigate and learn from the projects they are specifically interested in. Therefore, the idea here is to let the students decide on what projects they wish to review in a fair manner by placing a bidding policy.

== '''Problem Statement''' ==
The reviews performed by the students right now are being assigned on a first-come-first-serve basis. The task at hand is to implement a procedure so that the students can bid on the reviews that they would like to review, similar to the procedure of the assignment of the topics. The difference between the two procedures is that the assignment of the topic is a one-one mapping, i.e. a team is assigned to a single topic, whereas the assignment of the reviews is many-many mapping with each review being assigned to different students and each student assigned to different reviews.

=== '''The need for a bidding system for reviews''' ===

The bidding process, when implemented for reviews of projects, will hold several advantages.

1. The users will be able to bid for reviews that interest them. This will incentivize them to get a better understanding of the project requirements and provide the necessary feedback in an informed manner.

2. Bidding provides the users receiving feedback a very informed report on how to enhance their project. This will help them get better results for their respective projects.

3. The bidding also gives an advantage to the instructor because the instructor will now be able to receive more well-written, useful and meaningful feedback that will be more useful in their academic projects.

=== '''What needs to be done'''===
The following are the tasks that are to be done-

1. Implement top trading cycles on a web service as mentioned in the paper [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf].

The top trading cycles is an intelligent algorithm that allows users to achieve the review they will need. For example, let us consider a situation where user 'A' wants the review assigned to user 'B' and user 'B' wants the review assigned to user 'A'. Considering that it will motivate the students if they get the project that they would like to review, this mutual exchange between them would be beneficial. It can be solved using the top trading cycles algorithm.

[[File:bid.png |center|]]

'''Algorithm Steps'''

1) Let the user bid, these bids will point to the reviews they are requesting for in the graph.

2) There will be cycles links of length 1 between the person who owns ever review currently, a directed acyclic graph.

3) We will need to break all the cycles in the graph and assign the reviews to which the user is pointing at. The top is represent as [ TOP(i) ]

4) We can repeat this order until we have exhausted our preference list where all the assigned houses are constantly deleted.

5) we will repeat this bidding process for all slot of the bidding until the user gets all this review slots filled, making it many to many.

[[File:bid1.png |center|]]

From the diagram we can see that the three users are represented as u1, u2, u3 and the the three reviews are r1,r2,r3.

In '''phase 1''' : all users want the review 1 so all of them point to r1 and we see r1 is owned by u1 and r2 is owned by u2 and r3 by u3.

In '''phase 2''' : u1 is assigned r1 and now u2 points to r3 which is now its highest priority because r1 is removed and similarly u3 points to r2.

In '''phase 3''': r2 is assigned to u3 and and r3 is assigned to u2, thus satisfying all.

2. Add the front end code to allow the bidding on topics and call the appropriate web services from the lottery controller. This is similar to the already implemented bidding process on topics [https://github.com/expertiza/expertiza/pull/778/commits].

'''flow chart for this us functionality would involve :'''

[[File:flow.png |center|]]

=== '''Previous Work''' ===
The latest implementation of the problem was E1986 [https://github.com/expertiza/expertiza/pull/1629][https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor].

We can see that they have figured out the issues with the bidding assignement being one to one and not many to one and have succesfully used the Gale-Shapely version for many-to-many matching algorithm to solve the issues. They have also fixed a few problems with the UI that were being faced with the buttons and writing proper test cases.

From the previous implementations we can see that the following files were modified in order to get the required implementation they have modified the following files :

'''Modified Files'''

routes.rb

app/views/student_task/view.html.erb

app/views/assignments/edit.html.erb

app/controllers/student_task_controller

'''New Files'''

app/controllers/review_bidding.rb

app/models/review_bidding_controller.rb

app/views/sign_up_sheet/review_bid.html.erb

Source Code for the Web Service

=== '''Problems found in previous work''' ===
The problems in the previous work were given-

1. The link to the run bidding assignment is on the Review Strategy tab instead of the actions associated with an assignment like the topic assignment. This is an inconsistency in the UI that needs to be remedied.

2. All of the implementation code was put in the controller which is inappropriate for a controller. The code should probably be in the corresponding model file.

3. The tests that they have written are not adequate.

=== '''Suggested Improvements'''===

1. Change the location of the running bidding assignment to the appropriate location. This is because it is inconsistent with the UI and will require changes.

The part of the code that requires modification is : app/views/assignments/edit.html.erb

[[File:tab.PNG |center|]]

As we can see from the code attached we need to move this code away from the Review Strategy tab.

2. Write the code where it is suitable, following the DRY principles.

3. Write suitable tests to ensure that the implementation is working.

4. Make sure the reviewer can't bid for his own project.

=== '''Plan for Testing'''===

As of now, and as far as we understood the feature.

There are a few cases that need to be tested.

1) The first case would be to test for the scenario, where no reviewer bids i.e. no one has given a preference of any sort. Then the bidding algorithm should assign reviews randomly.

2) The other case would be when all reviewers have selected a different project as their preference, at different times. This is an ideal scenario given that the reviewer cannot bid for his own project.

3) The other scenario would be when everyone selects the same project at the same or different times and doesn't provide any other choice or preference. This can be the scenario if one project is relatively interesting or easy to review in comparison to the others in the roster.

4) Another scenario would be if some projects haven't been selected at all for reviewing, this case arises if the particular project may require additional effort on the part of the reviewing to successfully complete the review.

5) A usual scenario is that the reviewers select all or most of the projects, and each project is on at least one reviewers biding list.

== '''References''' ==
[1] [https://www.tayfunsonmez.net/wp-content/uploads/2013/10/AbdulkadirogluSonmez-AER20031.pdf School Choice: A Mechanism Design Approach] by Atila Abdulkadiroğlu and Tayfun Sönmez.

[2] [https://github.com/expertiza/expertiza/pull/778/commits Bidding Interface Implementation].

[3] [https://github.com/expertiza/expertiza/pull/1629 E1986 Pull Request].

[4] [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1986._Allow_reviewers_to_bid_on_what_to_review#Project_Mentor E1986 Wiki page].

CSC/ECE 517 Spring 2020 - M2000. Implement ImageBitMap web API

2020-03-31T22:40:26Z

Skmuppal:

A new browser technology that is being implemented with the new rust language to take advantage of the concurrency features of the language is the servo. [https://en.wikipedia.org/wiki/Rust_(programming_language)]. It is an innovation that will be using compiling in a very synchronous style as well as support things like web assembly code. It was an implementation that was a result of the effort of Mozilla research with aid from Samsung to help port it to android and arm processors. The servo does not yet have any support for the ImageBitmap which eventually makes it difficult to write it to the canvas in real-time without any undue latency in the process. This could lead to servo being slow and having very little graphical support, hence it will be requiring to implement support for ImageBitmap to make sure the process is smooth and efficient for graphical canvas support.

=='''Pull Request'''==

The pull request for this implementation has been merged.[https://github.com/servo/servo/pull/26009]

It passes all the test cases and also the build is passing.[https://github.com/servo/servo/pull/26009]

It contains only one commit as the servo DOM peer had asked us to squash all the commits into one for easier integration into the master servo implementation.

The whole list of commits can be found in the [https://github.com/servo/servo/pull/26009/commits/8c405546a2023c3e098d9450c2d755392d3d5c9c log details] of that commit.

=='''Comments for the code'''==

We will not be having detailed comments for each function of the code, because the servo community does not encourage comments which are not required.

The comments that are more than what is required will fail the servo build checks.

To make up for that, we try to explain wherever possible the code that we have written in this documentation.

=='''Introduction'''==

===Servo===
Servo [https://en.wikipedia.org/wiki/Servo_(layout_engine)] which is born as an intention from Mozilla to produce an open-source web engine that will work on the rust language implementation[https://www.rust-lang.org/]. It works on a parallel setup where the various rendering activities take place in a highly parallel nature.

The entire nature of flow for the servo is shown in the below diagram:

[[File:Flowofservo.png ]]

Here we can see that the servo parses the contents of html and css using dom, which runs on the rust scripts and produces a flow tree using the styling elements. It then renders them as layers which are produced as output using composition.[https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380]

===Rust===
Rust [https://doc.rust-lang.org/book/index.html] Rust again is born out of an intention from Mozilla to implement a programming language that is highly efficient for parallel processing that will make sure the threads are safe in execution and implementation. It is being used in the servo browser.

===DOM===
DOM stands for Document Object Model. It is a method that is being used by web-browsers to effectively arrange web pages and use them in a structured manner. Servo also uses the concept of dom to efficiently access the structure of how the web pages are stored and used effectively.

the general dom structure is shown below that has all head and body elements with a hyperlink :

[[File:dom.png ]]

===Scope===
Several browsers that we know have the ability to create images of bitmaps that can be reproduced for graphical purposes on canvas elements. The new servo browser from Mozilla is something that has canvas, thus the aim would be to implement code to support imagebitmap() for canvas in the servo.

[[File:Untitled_Diagram_(14).png ]]

===Image Bitmap===

Interface for imagebitmap[https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap] is something that represents an image which is a bitmap that can be drawn to a <canvas> [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas] without undue latency. the createimagebitmap() factory method is used to produce these images for implementation.

The general flow of an imagebitmap method would be :

[[File:bitmapgeneral.png]]

Here we see that the browser holds the main thread which will request the worker thread to obtain the URL that is being passed and uses it to create the image bitmap, Once the image has been created we will be transferring it back to the main thread where the canvas would be drawing the image created.[https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50]

===Implementation Steps===

The following steps have been implemented:

Step 1- add a ImageBitmap WebIDL interface to components/script/dom/webidls

Step 2- Implement its Rust code in components/script/dom/imagebitmap.rs that is backed by a Vec<u8> buffer

=='''Design Pattern'''==

Our project will not require any design patterns as it will only require the implementation of the methods. Please see below for the steps required in the implementation.

=='''Implementation'''==

The following are the steps that are present it the implementation project description [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project].

'''Step 1:''' add a ImageBitmap WebIDL interface [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl] to components/script/dom/webidls

The webidl information is from the official standard webidl[https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

Please note that we have removed the "Serializable" and "Transferable" components from the webidl as they are not required for this implementation.

[[File:Webidl.PNG]]

From the implemented the imagebitmap webidl for the dom struct that will be taking the height and width as its attributes.

The webidl specifies that it will hold an interface of the imagebitmap which will have attributes of height and width as unsigned long integers represent as the below diagram.

[[File:bitmap.png]]

enum specifies the various options that are available to the input image type that could be CanvasImageSouce or Blob or ImageData. The options will be used to manipulated these input types specifically - ImageOrientation, preMulitplyAlpha,ColourSpaceCoversion,ResizeQuality

[[File:enum.png]]

The imagebitmap options dictionary will be creating key-value pairs for these with initial default values as seen in the image below :

[[File:dict.png]]

'''Step 2:''' Create a imagebitmap.rs code implementation [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs] for the webidl

Below we have implemented the image bitmap rust code that uses all the crates[https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html]. Crates are the packages for rust implementation that can be imported.

[[File:rs_crates.PNG]]

The code here creates the crates for the rust implementation. The bitmap options are bound followed by binding to dom root and global scope. Fallible is used to check errors, Reflector is used to link the js side to the rust code. We also use vector of u8 charset to store the bitmap implementation

In the below image we can see the way the reflector object in the above code is used to access and link the javascript objects using rust. The rust node contains the reflector which is using to bind the javascript object every time a thing is manipulated on the rust side.

'''Reflector design in dom'''

[[File:Reflector.png]]

The dom_struct is the DOM structure that the ImageBitMap data has from the javascript object. It consists of the following-

1. Reflector - a reflector has the pointer to the required JavaScript object.

2. width and height - the width and the height part of the ImageBitMap's data as mentioned in the webidl file. The required datatype[https://doc.rust-lang.org/book/ch03-02-data-types.html] is 32-bit unsigned integers, denoted by u32.

3. As the imagebitmap needs to be implemented backed b a <Vec8> buffer, as mentioned in the problem statement, the DomRefCell<Vec<u8>> has been used. Where, u8 stands for 8-bit unsigned integer, which is used to hold the data of colour model[https://en.wikipedia.org/wiki/Color_model] and DOMRefCell is the RefCell[https://doc.rust-lang.org/std/cell/struct.RefCell.html] equivalent for the DOM implementation. RefCell is a wrapper used to make the data mutable, which is a required property here as the colour data might be altering.

[[File:rs_dom_struct.PNG]]

The image below shows how this struct is organised

[[File:struct.png]]

Here we implement the code that reads in the various attributes and the javascript objects required (shown below). We use the words '''impl ImageBitmap'''[https://doc.rust-lang.org/std/keyword.impl.html] which means the implementation of the ImageBitmap type. It will be using the '''newinherited''' and the '''new''' methods to obtain the required javascript objects and resolve the intended promises.

'''new_inheritence''' method is where the new instance of the ImageBitmap is created. '''new''' method is where the javascript object is connected to the ImageBitmap object[https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html].

[[File:rs_impl_ibm.PNG]]

Here we implement the code for the getter methods for '''height''' and '''width''' attributes for an ImageBitmap object. We use '''impl ImageBitmapMethods for ImageBitmap''' here which includes only the methods that are required as part of the implementation of the ImageBitmap.

[[File:rs_impl_methods.PNG]]

The height and width attributes are as shown below :

[[File:hw.png]]

The detailed description of the algorithm that has been implemented can be seen in the HTML Standard [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

'''Note''': Please note that the implementation does not have detailed comments as we were asked to remove them since they are against the servo implementation guidelines.

=='''How to Setup and Run'''==
The following are the steps to build the servo.

1. git clone the servo repository

2. setup all the pre-requisites[https://github.com/servo/servo/blob/master/README.md#on-windows-msvc]

3. switch into the "servo" directory - cd servo

4. build the project using:

4.1. For Windows

mach.bat build -dev

run the project using:

mach run -d -- https://github.com

4.2. For Linux / Mac-OS

./mach build --dev

run the project using:

./mach run --release tests/html/about-mozilla.html

=='''Test_Plan and Testing'''==

Upon successful completion of the setup and building the whole browser engine. You should get an output that is something similar to the image below.

[[File:Freak2.PNG]]

===Servo Building Test===

-> This completes the first step of testing as you will able to successfully run the software.

'''Note''': Please be aware that your system may hang up during the process as it involves compiling the whole code from source and this involves usage of the whole processing power of the local system. Don't fret yet, the system will come back to its normal state after the build is completed.

'''Note''': Time to compile depends on the CPU clock speed, and varies widely.

===Servo Tidiness test===

-> The next part of the testing involves checking for file tidiness, i.e. checking if all standards of the servo have been met.

Running the below command will test for the same.
[FOR LINUX / MAC-OS]

./mach test-tidy
./mach fmt

[FOR WINDOWS]

mach.bat test-tidy
mach.bat fmt

The output should be similar to the below picture which shows that the tests that were passed.

[[File:Freak.PNG]]

===Servo automated Unit-Testing===

-> The next part of testing is the unit-tests

Running the below command will run all unit-tests
[FOR LINUX / MAC-OS]

./mach test-unit

[FOR WINDOWS]

mach.bat test-unit

'''Note''': The output is too large to include everything here as images, and this [https://community-tc.services.mozilla.com/tasks/Zwl0KyYhTCSa6mEQ1QpsNg/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FZwl0KyYhTCSa6mEQ1QpsNg%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG FILE] has the full details of all the unit-tests passed.

===Servo Automated WPT Tests===

-> Then the next steps involve running the servo-provided automated WPT [Web Platform Tests] that are relevant for our implementation.

I am providing the commands to run the [https://github.com/servo/servo/blob/master/tests/wpt/README.md#running-the-tests WPT tests WPT Tests] on linux.

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html

To save the log results to a file, for example wpt.log

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html --log-raw wpt_dom.log

Once the test results are saved to the log, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations update the test expectations].

./mach update-wpt wpt_dom.log

Now to test another relevant feature for the above implementation and save it to a log file named wpt_interface-objects.log

./mach test-wpt tests/wpt/web-platform-tests/workers/semantics/interface-objects/001.worker.js --log-raw wpt_interface-objects.log

./mach update-wpt wpt_interface-objects.log [ UPDATING TEST EXPECTATIONS ]

'''Note''': The output can also be viewed in this [https://community-tc.services.mozilla.com/tasks/f-RoigFcT3iUzkSg9OunvA/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2Ff-RoigFcT3iUzkSg9OunvA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG_FILE] link.

===Manifest Update===

Now to cap it all off, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-the-wpt-manifest update the WPT manifest] so that all the changes have been registered and reflected appropriately.

It can be done by the command below.

./mach update-manifest

This finishes the testing for the code and you can see that the test coverage has increased.

=='''References'''==

[1] [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust Language Wikipedia]

[2] [https://en.wikipedia.org/wiki/Servo_(software) Servo Software Wikipedia]

[3] [https://www.rust-lang.org/ Rust Language Official Website]

[4] [https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380 servo working architecture]

[5] [https://doc.rust-lang.org/book/index.html Rust Language Textbook]

[6] [https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap ImageBitmap API Standard]

[7] [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas Canvas Element]

[8] [https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50 Bitmap flow]

[9] [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project Implement ImageBitmap problem statement]

[10] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl ImageBitmap WebIDL code]

[12] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap WebIDL Standard]

[13] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs ImageBitmap Rust code]

[14] [https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html Crates and Packages for Rust]

[14] [https://doc.rust-lang.org/book/ch03-02-data-types.html Data Types in Rust]

[15] [https://en.wikipedia.org/wiki/Color_model Color Model Wikipedia]

[16] [https://doc.rust-lang.org/std/cell/struct.RefCell.html RefCell in Rust]

[17] [https://doc.rust-lang.org/std/keyword.impl.html impl Keyword in Rust]

[18] [https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html Implement a new DOM tutorial]

[19] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap Algorithm]

[20] [https://github.com/servo/servo/pull/26009 ImageBitmap Implementation pull request]

[21] [https://github.com/servo/servo/blob/master/README.md#on-windows-msvc Build Pre-requisites for Rust]

[22] [https://github.com/servo/servo/blob/master/tests/wpt/README.md Testing the Servo Code]

CSC/ECE 517 Spring 2020 - M2000. Implement ImageBitMap web API

2020-03-31T22:32:01Z

Skmuppal:

A new browser technology that is being implemented with the new rust language to take advantage of the concurrency features of the language is the servo. [https://en.wikipedia.org/wiki/Rust_(programming_language)]. It is an innovation that will be using compiling in a very synchronous style as well as support things like web assembly code. It was an implementation that was a result of the effort of Mozilla research with aid from Samsung to help port it to android and arm processors. The servo does not yet have any support for the ImageBitmap which eventually makes it difficult to write it to the canvas in real-time without any undue latency in the process. This could lead to servo being slow and having very little graphical support, hence it will be requiring to implement support for ImageBitmap to make sure the process is smooth and efficient for graphical canvas support.

=='''Pull Request'''==

The pull request for this implementation has been merged.[https://github.com/servo/servo/pull/26009]

It passes all the test cases and also the build is passing.[https://github.com/servo/servo/pull/26009]

=='''Comments for the code'''==

We will not be having detailed comments for each function of the code, because the servo community does not encourage comments which are not required.

The comments that are more than what is required will fail the servo build checks.

To make up for that, we try to explain wherever possible the code that we have written in this documentation.

=='''Introduction'''==

===Servo===
Servo [https://en.wikipedia.org/wiki/Servo_(layout_engine)] which is born as an intention from Mozilla to produce an open-source web engine that will work on the rust language implementation[https://www.rust-lang.org/]. It works on a parallel setup where the various rendering activities take place in a highly parallel nature.

The entire nature of flow for the servo is shown in the below diagram:

[[File:Flowofservo.png ]]

Here we can see that the servo parses the contents of html and css using dom, which runs on the rust scripts and produces a flow tree using the styling elements. It then renders them as layers which are produced as output using composition.[https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380]

===Rust===
Rust [https://doc.rust-lang.org/book/index.html] Rust again is born out of an intention from Mozilla to implement a programming language that is highly efficient for parallel processing that will make sure the threads are safe in execution and implementation. It is being used in the servo browser.

===DOM===
DOM stands for Document Object Model. It is a method that is being used by web-browsers to effectively arrange web pages and use them in a structured manner. Servo also uses the concept of dom to efficiently access the structure of how the web pages are stored and used effectively.

the general dom structure is shown below that has all head and body elements with a hyperlink :

[[File:dom.png ]]

===Scope===
Several browsers that we know have the ability to create images of bitmaps that can be reproduced for graphical purposes on canvas elements. The new servo browser from Mozilla is something that has canvas, thus the aim would be to implement code to support imagebitmap() for canvas in the servo.

[[File:Untitled_Diagram_(14).png ]]

===Image Bitmap===

Interface for imagebitmap[https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap] is something that represents an image which is a bitmap that can be drawn to a <canvas> [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas] without undue latency. the createimagebitmap() factory method is used to produce these images for implementation.

The general flow of an imagebitmap method would be :

[[File:bitmapgeneral.png]]

Here we see that the browser holds the main thread which will request the worker thread to obtain the URL that is being passed and uses it to create the image bitmap, Once the image has been created we will be transferring it back to the main thread where the canvas would be drawing the image created.[https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50]

===Implementation Steps===

The following steps have been implemented:

Step 1- add a ImageBitmap WebIDL interface to components/script/dom/webidls

Step 2- Implement its Rust code in components/script/dom/imagebitmap.rs that is backed by a Vec<u8> buffer

=='''Design Pattern'''==

Our project will not require any design patterns as it will only require the implementation of the methods. Please see below for the steps required in the implementation.

=='''Implementation'''==

The following are the steps that are present it the implementation project description [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project].

'''Step 1:''' add a ImageBitmap WebIDL interface [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl] to components/script/dom/webidls

The webidl information is from the official standard webidl[https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

Please note that we have removed the "Serializable" and "Transferable" components from the webidl as they are not required for this implementation.

[[File:Webidl.PNG]]

From the implemented the imagebitmap webidl for the dom struct that will be taking the height and width as its attributes.

The webidl specifies that it will hold an interface of the imagebitmap which will have attributes of height and width as unsigned long integers represent as the below diagram.

[[File:bitmap.png]]

enum specifies the various options that are available to the input image type that could be CanvasImageSouce or Blob or ImageData. The options will be used to manipulated these input types specifically - ImageOrientation, preMulitplyAlpha,ColourSpaceCoversion,ResizeQuality

[[File:enum.png]]

The imagebitmap options dictionary will be creating key-value pairs for these with initial default values as seen in the image below :

[[File:dict.png]]

'''Step 2:''' Create a imagebitmap.rs code implementation [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs] for the webidl

Below we have implemented the image bitmap rust code that uses all the crates[https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html]. Crates are the packages for rust implementation that can be imported.

[[File:rs_crates.PNG]]

The code here creates the crates for the rust implementation. The bitmap options are bound followed by binding to dom root and global scope. Fallible is used to check errors, Reflector is used to link the js side to the rust code. We also use vector of u8 charset to store the bitmap implementation

In the below image we can see the way the reflector object in the above code is used to access and link the javascript objects using rust. The rust node contains the reflector which is using to bind the javascript object every time a thing is manipulated on the rust side.

'''Reflector design in dom'''

[[File:Reflector.png]]

The dom_struct is the DOM structure that the ImageBitMap data has from the javascript object. It consists of the following-

1. Reflector - a reflector has the pointer to the required JavaScript object.

2. width and height - the width and the height part of the ImageBitMap's data as mentioned in the webidl file. The required datatype[https://doc.rust-lang.org/book/ch03-02-data-types.html] is 32-bit unsigned integers, denoted by u32.

3. As the imagebitmap needs to be implemented backed b a <Vec8> buffer, as mentioned in the problem statement, the DomRefCell<Vec<u8>> has been used. Where, u8 stands for 8-bit unsigned integer, which is used to hold the data of colour model[https://en.wikipedia.org/wiki/Color_model] and DOMRefCell is the RefCell[https://doc.rust-lang.org/std/cell/struct.RefCell.html] equivalent for the DOM implementation. RefCell is a wrapper used to make the data mutable, which is a required property here as the colour data might be altering.

[[File:rs_dom_struct.PNG]]

The image below shows how this struct is organised

[[File:struct.png]]

Here we implement the code that reads in the various attributes and the javascript objects required (shown below). We use the words '''impl ImageBitmap'''[https://doc.rust-lang.org/std/keyword.impl.html] which means the implementation of the ImageBitmap type. It will be using the '''newinherited''' and the '''new''' methods to obtain the required javascript objects and resolve the intended promises.

'''new_inheritence''' method is where the new instance of the ImageBitmap is created. '''new''' method is where the javascript object is connected to the ImageBitmap object[https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html].

[[File:rs_impl_ibm.PNG]]

Here we implement the code for the getter methods for '''height''' and '''width''' attributes for an ImageBitmap object. We use '''impl ImageBitmapMethods for ImageBitmap''' here which includes only the methods that are required as part of the implementation of the ImageBitmap.

[[File:rs_impl_methods.PNG]]

The height and width attributes are as shown below :

[[File:hw.png]]

The detailed description of the algorithm that has been implemented can be seen in the HTML Standard [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

'''Note''': Please note that the implementation does not have detailed comments as we were asked to remove them since they are against the servo implementation guidelines.

=='''How to Setup and Run'''==
The following are the steps to build the servo.

1. git clone the servo repository

2. setup all the pre-requisites[https://github.com/servo/servo/blob/master/README.md#on-windows-msvc]

3. switch into the "servo" directory - cd servo

4. build the project using:

4.1. For Windows

mach.bat build -dev

run the project using:

mach run -d -- https://github.com

4.2. For Linux / Mac-OS

./mach build --dev

run the project using:

./mach run --release tests/html/about-mozilla.html

=='''Test_Plan and Testing'''==

Upon successful completion of the setup and building the whole browser engine. You should get an output that is something similar to the image below.

[[File:Freak2.PNG]]

===Servo Building Test===

-> This completes the first step of testing as you will able to successfully run the software.

'''Note''': Please be aware that your system may hang up during the process as it involves compiling the whole code from source and this involves usage of the whole processing power of the local system. Don't fret yet, the system will come back to its normal state after the build is completed.

'''Note''': Time to compile depends on the CPU clock speed, and varies widely.

===Servo Tidiness test===

-> The next part of the testing involves checking for file tidiness, i.e. checking if all standards of the servo have been met.

Running the below command will test for the same.
[FOR LINUX / MAC-OS]

./mach test-tidy
./mach fmt

[FOR WINDOWS]

mach.bat test-tidy
mach.bat fmt

The output should be similar to the below picture which shows that the tests that were passed.

[[File:Freak.PNG]]

===Servo automated Unit-Testing===

-> The next part of testing is the unit-tests

Running the below command will run all unit-tests
[FOR LINUX / MAC-OS]

./mach test-unit

[FOR WINDOWS]

mach.bat test-unit

'''Note''': The output is too large to include everything here as images, and this [https://community-tc.services.mozilla.com/tasks/Zwl0KyYhTCSa6mEQ1QpsNg/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FZwl0KyYhTCSa6mEQ1QpsNg%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG FILE] has the full details of all the unit-tests passed.

===Servo Automated WPT Tests===

-> Then the next steps involve running the servo-provided automated WPT [Web Platform Tests] that are relevant for our implementation.

I am providing the commands to run the [https://github.com/servo/servo/blob/master/tests/wpt/README.md#running-the-tests WPT tests WPT Tests] on linux.

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html

To save the log results to a file, for example wpt.log

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html --log-raw wpt_dom.log

Once the test results are saved to the log, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations update the test expectations].

./mach update-wpt wpt_dom.log

Now to test another relevant feature for the above implementation and save it to a log file named wpt_interface-objects.log

./mach test-wpt tests/wpt/web-platform-tests/workers/semantics/interface-objects/001.worker.js --log-raw wpt_interface-objects.log

./mach update-wpt wpt_interface-objects.log [ UPDATING TEST EXPECTATIONS ]

'''Note''': The output can also be viewed in this [https://community-tc.services.mozilla.com/tasks/f-RoigFcT3iUzkSg9OunvA/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2Ff-RoigFcT3iUzkSg9OunvA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG_FILE] link.

===Manifest Update===

Now to cap it all off, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-the-wpt-manifest update the WPT manifest] so that all the changes have been registered and reflected appropriately.

It can be done by the command below.

./mach update-manifest

This finishes the testing for the code and you can see that the test coverage has increased.

=='''References'''==

[1] [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust Language Wikipedia]

[2] [https://en.wikipedia.org/wiki/Servo_(software) Servo Software Wikipedia]

[3] [https://www.rust-lang.org/ Rust Language Official Website]

[4] [https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380 servo working architecture]

[5] [https://doc.rust-lang.org/book/index.html Rust Language Textbook]

[6] [https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap ImageBitmap API Standard]

[7] [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas Canvas Element]

[8] [https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50 Bitmap flow]

[9] [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project Implement ImageBitmap problem statement]

[10] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl ImageBitmap WebIDL code]

[12] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap WebIDL Standard]

[13] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs ImageBitmap Rust code]

[14] [https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html Crates and Packages for Rust]

[14] [https://doc.rust-lang.org/book/ch03-02-data-types.html Data Types in Rust]

[15] [https://en.wikipedia.org/wiki/Color_model Color Model Wikipedia]

[16] [https://doc.rust-lang.org/std/cell/struct.RefCell.html RefCell in Rust]

[17] [https://doc.rust-lang.org/std/keyword.impl.html impl Keyword in Rust]

[18] [https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html Implement a new DOM tutorial]

[19] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap Algorithm]

[20] [https://github.com/servo/servo/pull/26009 ImageBitmap Implementation pull request]

[21] [https://github.com/servo/servo/blob/master/README.md#on-windows-msvc Build Pre-requisites for Rust]

[22] [https://github.com/servo/servo/blob/master/tests/wpt/README.md Testing the Servo Code]

CSC/ECE 517 Spring 2020 - M2000. Implement ImageBitMap web API

2020-03-31T22:27:02Z

Skmuppal:

A new browser technology that is being implemented with the new rust language to take advantage of the concurrency features of the language is the servo. [https://en.wikipedia.org/wiki/Rust_(programming_language)]. It is an innovation that will be using compiling in a very synchronous style as well as support things like web assembly code. It was an implementation that was a result of the effort of Mozilla research with aid from Samsung to help port it to android and arm processors. The servo does not yet have any support for the ImageBitmap which eventually makes it difficult to write it to the canvas in real-time without any undue latency in the process. This could lead to servo being slow and having very little graphical support, hence it will be requiring to implement support for ImageBitmap to make sure the process is smooth and efficient for graphical canvas support.

=='''Pull Request'''==

The pull request for this implementation has been merged.[https://github.com/servo/servo/pull/26009]

It passes all the test cases and also the build is passing.[https://github.com/servo/servo/pull/26009]

=='''Comments for the code'''==

We will not be having detailed comments for each function of the code, because the servo community does not encourage comments which are not required.

The comments that are more than what is required will fail the servo build checks.

To make up for that, we try to explain wherever possible the code that we have written in this documentation.

=='''Introduction'''==

===Servo===
Servo [https://en.wikipedia.org/wiki/Servo_(layout_engine)] which is born as an intention from Mozilla to produce an open-source web engine that will work on the rust language implementation[https://www.rust-lang.org/]. It works on a parallel setup where the various rendering activities take place in a highly parallel nature.

The entire nature of flow for the servo is shown in the below diagram:

[[File:Flowofservo.png ]]

Here we can see that the servo parses the contents of html and css using dom, which runs on the rust scripts and produces a flow tree using the styling elements. It then renders them as layers which are produced as output using composition.[https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380]

===Rust===
Rust [https://doc.rust-lang.org/book/index.html] Rust again is born out of an intention from Mozilla to implement a programming language that is highly efficient for parallel processing that will make sure the threads are safe in execution and implementation. It is being used in the servo browser.

===DOM===
DOM stands for Document Object Model. It is a method that is being used by web-browsers to effectively arrange web pages and use them in a structured manner. Servo also uses the concept of dom to efficiently access the structure of how the web pages are stored and used effectively.

the general dom structure is shown below that has all head and body elements with a hyperlink :

[[File:dom.png ]]

===Scope===
Several browsers that we know have the ability to create images of bitmaps that can be reproduced for graphical purposes on canvas elements. The new servo browser from Mozilla is something that has canvas, thus the aim would be to implement code to support imagebitmap() for canvas in the servo.

[[File:Untitled_Diagram_(14).png ]]

===Image Bitmap===

Interface for imagebitmap[https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap] is something that represents an image which is a bitmap that can be drawn to a <canvas> [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas] without undue latency. the createimagebitmap() factory method is used to produce these images for implementation.

The general flow of an imagebitmap method would be :

[[File:bitmapgeneral.png]]

Here we see that the browser holds the main thread which will request the worker thread to obtain the URL that is being passed and uses it to create the image bitmap, Once the image has been created we will be transferring it back to the main thread where the canvas would be drawing the image created.[https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50]

===Implementation Steps===

The following steps have been implemented:

Step 1- add a ImageBitmap WebIDL interface to components/script/dom/webidls

Step 2- Implement its Rust code in components/script/dom/imagebitmap.rs that is backed by a Vec<u8> buffer

=='''Design Pattern'''==

Our project will not require any design patterns as it will only require the implementation of the methods. Please see below for the steps required in the implementation.

=='''Implementation'''==

The following are the steps that are present it the implementation project description [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project].

'''Step 1:''' add a ImageBitmap WebIDL interface [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl] to components/script/dom/webidls

The webidl information is from the official standard webidl[https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

Please note that we have removed the "Serializable" and "Transferable" components from the webidl as they are not required for this implementation.

[[File:Webidl.PNG]]

From the implemented the imagebitmap webidl for the dom struct that will be taking the height and width as its attributes.

The webidl specifies that it will hold an interface of the imagebitmap which will have attributes of height and width as unsigned long integers represent as the below diagram.

[[File:bitmap.png]]

enum specifies the various options that are available to the input image type that could be CanvasImageSouce or Blob or ImageData. The options will be used to manipulated these input types specifically - ImageOrientation, preMulitplyAlpha,ColourSpaceCoversion,ResizeQuality

[[File:enum.png]]

The imagebitmap options dictionary will be creating key-value pairs for these with initial default values as seen in the image below :

[[File:dict.png]]

'''Step 2:''' Create a imagebitmap.rs code implementation [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs] for the webidl

Below we have implemented the image bitmap rust code that uses all the crates[https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html]. Crates are the packages for rust implementation that can be imported.

[[File:rs_crates.PNG]]

The code here creates the crates for the rust implementation. The bitmap options are bound followed by binding to dom root and global scope. Fallible is used to check errors, Reflector is used to link the js side to the rust code. We also use vector of u8 charset to store the bitmap implementation

In the below image we can see the way the reflector object in the above code is used to access and link the javascript objects using rust. The rust node contains the reflector which is using to bind the javascript object every time a thing is manipulated on the rust side.

'''Reflector design in dom'''

[[File:Reflector.png]]

The dom_struct is the DOM structure that the ImageBitMap data has from the javascript object. It consists of the following-

1. Reflector - a reflector has the pointer to the required JavaScript object.

2. width and height - the width and the height part of the ImageBitMap's data as mentioned in the webidl file. The required datatype[https://doc.rust-lang.org/book/ch03-02-data-types.html] is 32-bit unsigned integers, denoted by u32.

3. As the imagebitmap needs to be implemented backed b a <Vec8> buffer, as mentioned in the problem statement, the DomRefCell<Vec<u8>> has been used. Where, u8 stands for 8-bit unsigned integer, which is used to hold the data of colour model[https://en.wikipedia.org/wiki/Color_model] and DOMRefCell is the RefCell[https://doc.rust-lang.org/std/cell/struct.RefCell.html] equivalent for the DOM implementation. RefCell is a wrapper used to make the data mutable, which is a required property here as the colour data might be altering.

[[File:rs_dom_struct.PNG]]

The image below shows how this struct is organised

[[File:struct.png]]

Here we implement the code that reads in the various attributes and the javascript objects required (shown below). We use the words '''impl ImageBitmap'''[https://doc.rust-lang.org/std/keyword.impl.html] which means the implementation of the ImageBitmap type. It will be using the '''newinherited''' and the '''new''' methods to obtain the required javascript objects and resolve the intended promises.

'''new_inheritence''' method is where the new instance of the ImageBitmap is created. '''new''' method is where the javascript object is connected to the ImageBitmap object[https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html].

[[File:rs_impl_ibm.PNG]]

Here we implement the code for the getter methods for '''height''' and '''width''' attributes for an ImageBitmap object. We use '''impl ImageBitmapMethods for ImageBitmap''' here which includes only the methods that are required as part of the implementation of the ImageBitmap.

[[File:rs_impl_methods.PNG]]

The height and width attributes are as shown below :

[[File:hw.png]]

The detailed description of the algorithm that has been implemented can be seen in the HTML Standard [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

'''Note''': Please note that the implementation does not have detailed comments as we were asked to remove them since they are against the servo implementation guidelines.

=='''How to Setup and Run'''==
The following are the steps to build the servo.

1. git clone the servo repository

2. setup all the pre-requisites[https://github.com/servo/servo/blob/master/README.md#on-windows-msvc]

3. switch into the "servo" directory - cd servo

4. build the project using:

4.1. For Windows

mach.bat build -dev

run the project using:

mach run -d -- https://github.com

4.2. For Linux / Mac-OS

./mach build --dev

run the project using:

./mach run --release tests/html/about-mozilla.html

=='''Test_Plan and Testing'''==

Upon successful completion of the setup and building the whole browser engine. You should get an output that is something similar to the image below.

[[File:Freak2.PNG]]

===Servo Building Test===

-> This completes the first step of testing as you will able to successfully run the software.

'''Note''': Please be aware that your system may hang up during the process as it involves compiling the whole code from source and this involves usage of the whole processing power of the local system. Don't fret yet, the system will come back to its normal state after the build is completed.

'''Note''': Time to compile depends on the CPU clock speed, and varies widely.

===Servo Tidiness test===

-> The next part of the testing involves checking for file tidiness, i.e. checking if all standards of the servo have been met.

Running the below command will test for the same.
[FOR LINUX / MAC-OS]

./mach test-tidy
./mach fmt

[FOR WINDOWS]

mach.bat test-tidy
mach.bat fmt

The output should be similar to the below picture which shows that the tests that were passed.

[[File:Freak.PNG]]

===Servo automated Unit-Testing===

-> The next part of testing is the unit-tests

Running the below command will run all unit-tests

./mach test-unit [FOR LINUX / MAC-OS]

mach.bat test-unit [FOR WINDOWS]

'''Note''': The output is too large to include everything here as images, and this [https://community-tc.services.mozilla.com/tasks/Zwl0KyYhTCSa6mEQ1QpsNg/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FZwl0KyYhTCSa6mEQ1QpsNg%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG FILE] has the full details of all the unit-tests passed.

===Servo Automated WPT Tests===

-> Then the next steps involve running the servo-provided automated WPT [Web Platform Tests] that are relevant for our implementation.

I am providing the commands to run the [https://github.com/servo/servo/blob/master/tests/wpt/README.md#running-the-tests WPT tests] on Linux

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html

To save the log results to a file, for example wpt.log

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html --log-raw wpt_dom.log

Once the test results are saved to the log, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations update the test expectations].

./mach update-wpt wpt_dom.log

Now to test another relevant feature for the above implementation and save it to a log file named wpt_interface-objects.log

./mach test-wpt tests/wpt/web-platform-tests/workers/semantics/interface-objects/001.worker.js --log-raw wpt_interface-objects.log

./mach update-wpt wpt_interface-objects.log [ UPDATING TEST EXPECTATIONS ]

'''Note''': The output can also be viewed in this [https://community-tc.services.mozilla.com/tasks/f-RoigFcT3iUzkSg9OunvA/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2Ff-RoigFcT3iUzkSg9OunvA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG_FILE] link.

===Manifest Update===

Now to cap it all off, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-the-wpt-manifest update the WPT manifest] so that all the changes have been registered and reflected appropriately.

It can be done by the command below.

./mach update-manifest

This finishes the testing for the code and you can see that the test coverage has increased.

=='''References'''==

[1] [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust Language Wikipedia]

[2] [https://en.wikipedia.org/wiki/Servo_(software) Servo Software Wikipedia]

[3] [https://www.rust-lang.org/ Rust Language Official Website]

[4] [https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380 servo working architecture]

[5] [https://doc.rust-lang.org/book/index.html Rust Language Textbook]

[6] [https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap ImageBitmap API Standard]

[7] [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas Canvas Element]

[8] [https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50 Bitmap flow]

[9] [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project Implement ImageBitmap problem statement]

[10] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl ImageBitmap WebIDL code]

[12] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap WebIDL Standard]

[13] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs ImageBitmap Rust code]

[14] [https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html Crates and Packages for Rust]

[14] [https://doc.rust-lang.org/book/ch03-02-data-types.html Data Types in Rust]

[15] [https://en.wikipedia.org/wiki/Color_model Color Model Wikipedia]

[16] [https://doc.rust-lang.org/std/cell/struct.RefCell.html RefCell in Rust]

[17] [https://doc.rust-lang.org/std/keyword.impl.html impl Keyword in Rust]

[18] [https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html Implement a new DOM tutorial]

[19] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap Algorithm]

[20] [https://github.com/servo/servo/pull/26009 ImageBitmap Implementation pull request]

[21] [https://github.com/servo/servo/blob/master/README.md#on-windows-msvc Build Pre-requisites for Rust]

[22] [https://github.com/servo/servo/blob/master/tests/wpt/README.md Testing the Servo Code]

CSC/ECE 517 Spring 2020 - M2000. Implement ImageBitMap web API

2020-03-31T22:25:16Z

Skmuppal:

A new browser technology that is being implemented with the new rust language to take advantage of the concurrency features of the language is the servo. [https://en.wikipedia.org/wiki/Rust_(programming_language)]. It is an innovation that will be using compiling in a very synchronous style as well as support things like web assembly code. It was an implementation that was a result of the effort of Mozilla research with aid from Samsung to help port it to android and arm processors. The servo does not yet have any support for the ImageBitmap which eventually makes it difficult to write it to the canvas in real-time without any undue latency in the process. This could lead to servo being slow and having very little graphical support, hence it will be requiring to implement support for ImageBitmap to make sure the process is smooth and efficient for graphical canvas support.

=='''Pull Request'''==

The pull request for this implementation has been merged.[https://github.com/servo/servo/pull/26009]

It passes all the test cases and also the build is passing.[https://github.com/servo/servo/pull/26009]

=='''Comments for the code'''==

We will not be having detailed comments for each function of the code, because the servo community does not encourage comments which are not required.

The comments that are more than what is required will fail the servo build checks.

To make up for that, we try to explain wherever possible the code that we have written in this documentation.

=='''Introduction'''==

===Servo===
Servo [https://en.wikipedia.org/wiki/Servo_(layout_engine)] which is born as an intention from Mozilla to produce an open-source web engine that will work on the rust language implementation[https://www.rust-lang.org/]. It works on a parallel setup where the various rendering activities take place in a highly parallel nature.

The entire nature of flow for the servo is shown in the below diagram:

[[File:Flowofservo.png ]]

Here we can see that the servo parses the contents of html and css using dom, which runs on the rust scripts and produces a flow tree using the styling elements. It then renders them as layers which are produced as output using composition.[https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380]

===Rust===
Rust [https://doc.rust-lang.org/book/index.html] Rust again is born out of an intention from Mozilla to implement a programming language that is highly efficient for parallel processing that will make sure the threads are safe in execution and implementation. It is being used in the servo browser.

===DOM===
DOM stands for Document Object Model. It is a method that is being used by web-browsers to effectively arrange web pages and use them in a structured manner. Servo also uses the concept of dom to efficiently access the structure of how the web pages are stored and used effectively.

the general dom structure is shown below that has all head and body elements with a hyperlink :

[[File:dom.png ]]

===Scope===
Several browsers that we know have the ability to create images of bitmaps that can be reproduced for graphical purposes on canvas elements. The new servo browser from Mozilla is something that has canvas, thus the aim would be to implement code to support imagebitmap() for canvas in the servo.

[[File:Untitled_Diagram_(14).png ]]

===Image Bitmap===

Interface for imagebitmap[https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap] is something that represents an image which is a bitmap that can be drawn to a <canvas> [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas] without undue latency. the createimagebitmap() factory method is used to produce these images for implementation.

The general flow of an imagebitmap method would be :

[[File:bitmapgeneral.png]]

Here we see that the browser holds the main thread which will request the worker thread to obtain the URL that is being passed and uses it to create the image bitmap, Once the image has been created we will be transferring it back to the main thread where the canvas would be drawing the image created.[https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50]

===Implementation Steps===

The following steps have been implemented:

Step 1- add a ImageBitmap WebIDL interface to components/script/dom/webidls

Step 2- Implement its Rust code in components/script/dom/imagebitmap.rs that is backed by a Vec<u8> buffer

=='''Design Pattern'''==

Our project will not require any design patterns as it will only require the implementation of the methods. Please see below for the steps required in the implementation.

=='''Implementation'''==

The following are the steps that are present it the implementation project description [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project].

'''Step 1:''' add a ImageBitmap WebIDL interface [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl] to components/script/dom/webidls

The webidl information is from the official standard webidl[https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

Please note that we have removed the "Serializable" and "Transferable" components from the webidl as they are not required for this implementation.

[[File:Webidl.PNG]]

From the implemented the imagebitmap webidl for the dom struct that will be taking the height and width as its attributes.

The webidl specifies that it will hold an interface of the imagebitmap which will have attributes of height and width as unsigned long integers represent as the below diagram.

[[File:bitmap.png]]

enum specifies the various options that are available to the input image type that could be CanvasImageSouce or Blob or ImageData. The options will be used to manipulated these input types specifically - ImageOrientation, preMulitplyAlpha,ColourSpaceCoversion,ResizeQuality

[[File:enum.png]]

The imagebitmap options dictionary will be creating key-value pairs for these with initial default values as seen in the image below :

[[File:dict.png]]

'''Step 2:''' Create a imagebitmap.rs code implementation [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs] for the webidl

Below we have implemented the image bitmap rust code that uses all the crates[https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html]. Crates are the packages for rust implementation that can be imported.

[[File:rs_crates.PNG]]

The code here creates the crates for the rust implementation. The bitmap options are bound followed by binding to dom root and global scope. Fallible is used to check errors, Reflector is used to link the js side to the rust code. We also use vector of u8 charset to store the bitmap implementation

In the below image we can see the way the reflector object in the above code is used to access and link the javascript objects using rust. The rust node contains the reflector which is using to bind the javascript object every time a thing is manipulated on the rust side.

'''Reflector design in dom'''

[[File:Reflector.png]]

The dom_struct is the DOM structure that the ImageBitMap data has from the javascript object. It consists of the following-

1. Reflector - a reflector has the pointer to the required JavaScript object.

2. width and height - the width and the height part of the ImageBitMap's data as mentioned in the webidl file. The required datatype[https://doc.rust-lang.org/book/ch03-02-data-types.html] is 32-bit unsigned integers, denoted by u32.

3. As the imagebitmap needs to be implemented backed b a <Vec8> buffer, as mentioned in the problem statement, the DomRefCell<Vec<u8>> has been used. Where, u8 stands for 8-bit unsigned integer, which is used to hold the data of colour model[https://en.wikipedia.org/wiki/Color_model] and DOMRefCell is the RefCell[https://doc.rust-lang.org/std/cell/struct.RefCell.html] equivalent for the DOM implementation. RefCell is a wrapper used to make the data mutable, which is a required property here as the colour data might be altering.

[[File:rs_dom_struct.PNG]]

The image below shows how this struct is organised

[[File:struct.png]]

Here we implement the code that reads in the various attributes and the javascript objects required (shown below). We use the words '''impl ImageBitmap'''[https://doc.rust-lang.org/std/keyword.impl.html] which means the implementation of the ImageBitmap type. It will be using the '''newinherited''' and the '''new''' methods to obtain the required javascript objects and resolve the intended promises.

'''new_inheritence''' method is where the new instance of the ImageBitmap is created. '''new''' method is where the javascript object is connected to the ImageBitmap object[https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html].

[[File:rs_impl_ibm.PNG]]

Here we implement the code for the getter methods for '''height''' and '''width''' attributes for an ImageBitmap object. We use '''impl ImageBitmapMethods for ImageBitmap''' here which includes only the methods that are required as part of the implementation of the ImageBitmap.

[[File:rs_impl_methods.PNG]]

The height and width attributes are as shown below :

[[File:hw.png]]

The detailed description of the algorithm that has been implemented can be seen in the HTML Standard [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

'''Note''': Please note that the implementation does not have detailed comments as we were asked to remove them since they are against the servo implementation guidelines.

=='''How to Setup and Run'''==
The following are the steps to build the servo.

1. git clone the servo repository

2. setup all the pre-requisites[https://github.com/servo/servo/blob/master/README.md#on-windows-msvc]

3. switch into the "servo" directory - cd servo

4. build the project using:

4.1. For Windows

mach.bat build -dev

run the project using:

mach run -d -- https://github.com

4.2. For Linux / Mac-OS

./mach build --dev

run the project using:

./mach run --release tests/html/about-mozilla.html

=='''Test_Plan and Testing'''==

Upon successful completion of the setup and building the whole browser engine. You should get an output that is something similar to the image below.

[[File:Freak2.PNG]]

===Servo Building Test===

-> This completes the first step of testing as you will able to successfully run the software.

'''Note''': Please be aware that your system may hang up during the process as it involves compiling the whole code from source and this involves usage of the whole processing power of the local system. Don't fret yet, the system will come back to its normal state after the build is completed.

'''Note''': Time to compile depends on the CPU clock speed, and varies widely.

===Servo Tidiness test===

-> The next part of the testing involves checking for file tidiness, i.e. checking if all standards of the servo have been met.

Running the below command will test for the same.
[FOR LINUX / MAC-OS]

./mach test-tidy
./mach fmt

[FOR WINDOWS]

mach.bat test-tidy
mach.bat fmt

The output should be similar to the below picture which shows that the tests that were passed.

[[File:Freak.PNG]]

===Servo automated Unit-Testing===

-> The next part of testing is the unit-tests

Running the below command will run all unit-tests

./mach test-unit [FOR LINUX / MAC-OS]

mach.bat test-unit [FOR WINDOWS]

'''Note''': The output is too large to include everything here image here but this [https://community-tc.services.mozilla.com/tasks/Zwl0KyYhTCSa6mEQ1QpsNg/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FZwl0KyYhTCSa6mEQ1QpsNg%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG FILE] has the full details of all the unit-tests passed.

===Servo Automated WPT Tests===

-> Then the next steps involve running the servo-provided automated WPT [Web Platform Tests] that are relevant for our implementation.

I am providing the commands to run the [https://github.com/servo/servo/blob/master/tests/wpt/README.md#running-the-tests WPT tests] on Linux

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html

To save the log results to a file, for example wpt.log

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html --log-raw wpt_dom.log

Once the test results are saved to the log, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations update the test expectations].

./mach update-wpt wpt_dom.log

Now to test another relevant feature for the above implementation and save it to a log file named wpt_interface-objects.log

./mach test-wpt tests/wpt/web-platform-tests/workers/semantics/interface-objects/001.worker.js --log-raw wpt_interface-objects.log

./mach update-wpt wpt_interface-objects.log [ UPDATING TEST EXPECTATIONS ]

'''Note''': The output can also be viewed in this [https://community-tc.services.mozilla.com/tasks/f-RoigFcT3iUzkSg9OunvA/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2Ff-RoigFcT3iUzkSg9OunvA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG_FILE] link.

===Manifest Update===

Now to cap it all off, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-the-wpt-manifest update the WPT manifest] so that all the changes have been registered and reflected appropriately.

It can be done by the command below.

./mach update-manifest

This finishes the testing for the code and you can see that the test coverage has increased.

=='''References'''==

[1] [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust Language Wikipedia]

[2] [https://en.wikipedia.org/wiki/Servo_(software) Servo Software Wikipedia]

[3] [https://www.rust-lang.org/ Rust Language Official Website]

[4] [https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380 servo working architecture]

[5] [https://doc.rust-lang.org/book/index.html Rust Language Textbook]

[6] [https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap ImageBitmap API Standard]

[7] [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas Canvas Element]

[8] [https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50 Bitmap flow]

[9] [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project Implement ImageBitmap problem statement]

[10] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl ImageBitmap WebIDL code]

[12] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap WebIDL Standard]

[13] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs ImageBitmap Rust code]

[14] [https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html Crates and Packages for Rust]

[14] [https://doc.rust-lang.org/book/ch03-02-data-types.html Data Types in Rust]

[15] [https://en.wikipedia.org/wiki/Color_model Color Model Wikipedia]

[16] [https://doc.rust-lang.org/std/cell/struct.RefCell.html RefCell in Rust]

[17] [https://doc.rust-lang.org/std/keyword.impl.html impl Keyword in Rust]

[18] [https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html Implement a new DOM tutorial]

[19] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap Algorithm]

[20] [https://github.com/servo/servo/pull/26009 ImageBitmap Implementation pull request]

[21] [https://github.com/servo/servo/blob/master/README.md#on-windows-msvc Build Pre-requisites for Rust]

[22] [https://github.com/servo/servo/blob/master/tests/wpt/README.md Testing the Servo Code]

CSC/ECE 517 Spring 2020 - M2000. Implement ImageBitMap web API

2020-03-31T22:18:12Z

Skmuppal:

A new browser technology that is being implemented with the new rust language to take advantage of the concurrency features of the language is the servo. [https://en.wikipedia.org/wiki/Rust_(programming_language)]. It is an innovation that will be using compiling in a very synchronous style as well as support things like web assembly code. It was an implementation that was a result of the effort of Mozilla research with aid from Samsung to help port it to android and arm processors. The servo does not yet have any support for the ImageBitmap which eventually makes it difficult to write it to the canvas in real-time without any undue latency in the process. This could lead to servo being slow and having very little graphical support, hence it will be requiring to implement support for ImageBitmap to make sure the process is smooth and efficient for graphical canvas support.

=='''Pull Request'''==

The pull request for this implementation has been merged.[https://github.com/servo/servo/pull/26009]

It passes all the test cases and also the build is passing.[https://github.com/servo/servo/pull/26009]

=='''Comments for the code'''==

We will not be having detailed comments for each function of the code, because the servo community does not encourage comments which are not required.

The comments that are more than what is required will fail the servo build checks.

To make up for that, we try to explain wherever possible the code that we have written in this documentation.

=='''Introduction'''==

===Servo===
Servo [https://en.wikipedia.org/wiki/Servo_(layout_engine)] which is born as an intention from Mozilla to produce an open-source web engine that will work on the rust language implementation[https://www.rust-lang.org/]. It works on a parallel setup where the various rendering activities take place in a highly parallel nature.

The entire nature of flow for the servo is shown in the below diagram:

[[File:Flowofservo.png ]]

Here we can see that the servo parses the contents of html and css using dom, which runs on the rust scripts and produces a flow tree using the styling elements. It then renders them as layers which are produced as output using composition.[https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380]

===Rust===
Rust [https://doc.rust-lang.org/book/index.html] Rust again is born out of an intention from Mozilla to implement a programming language that is highly efficient for parallel processing that will make sure the threads are safe in execution and implementation. It is being used in the servo browser.

===DOM===
DOM stands for Document Object Model. It is a method that is being used by web-browsers to effectively arrange web pages and use them in a structured manner. Servo also uses the concept of dom to efficiently access the structure of how the web pages are stored and used effectively.

the general dom structure is shown below that has all head and body elements with a hyperlink :

[[File:dom.png ]]

===Scope===
Several browsers that we know have the ability to create images of bitmaps that can be reproduced for graphical purposes on canvas elements. The new servo browser from Mozilla is something that has canvas, thus the aim would be to implement code to support imagebitmap() for canvas in the servo.

[[File:Untitled_Diagram_(14).png ]]

===Image Bitmap===

Interface for imagebitmap[https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap] is something that represents an image which is a bitmap that can be drawn to a <canvas> [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas] without undue latency. the createimagebitmap() factory method is used to produce these images for implementation.

The general flow of an imagebitmap method would be :

[[File:bitmapgeneral.png]]

Here we see that the browser holds the main thread which will request the worker thread to obtain the URL that is being passed and uses it to create the image bitmap, Once the image has been created we will be transferring it back to the main thread where the canvas would be drawing the image created.[https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50]

===Implementation Steps===

The following steps have been implemented:

Step 1- add a ImageBitmap WebIDL interface to components/script/dom/webidls

Step 2- Implement its Rust code in components/script/dom/imagebitmap.rs that is backed by a Vec<u8> buffer

=='''Design Pattern'''==

Our project will not require any design patterns as it will only require the implementation of the methods. Please see below for the steps required in the implementation.

=='''Implementation'''==

The following are the steps that are present it the implementation project description [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project].

'''Step 1:''' add a ImageBitmap WebIDL interface [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl] to components/script/dom/webidls

The webidl information is from the official standard webidl[https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

Please note that we have removed the "Serializable" and "Transferable" components from the webidl as they are not required for this implementation.

[[File:Webidl.PNG]]

From the implemented the imagebitmap webidl for the dom struct that will be taking the height and width as its attributes.

The webidl specifies that it will hold an interface of the imagebitmap which will have attributes of height and width as unsigned long integers represent as the below diagram.

[[File:bitmap.png]]

enum specifies the various options that are available to the input image type that could be CanvasImageSouce or Blob or ImageData. The options will be used to manipulated these input types specifically - ImageOrientation, preMulitplyAlpha,ColourSpaceCoversion,ResizeQuality

[[File:enum.png]]

The imagebitmap options dictionary will be creating key-value pairs for these with initial default values as seen in the image below :

[[File:dict.png]]

'''Step 2:''' Create a imagebitmap.rs code implementation [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs] for the webidl

Below we have implemented the image bitmap rust code that uses all the crates[https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html]. Crates are the packages for rust implementation that can be imported.

[[File:rs_crates.PNG]]

The code here creates the crates for the rust implementation. The bitmap options are bound followed by binding to dom root and global scope. Fallible is used to check errors, Reflector is used to link the js side to the rust code. We also use vector of u8 charset to store the bitmap implementation

In the below image we can see the way the reflector object in the above code is used to access and link the javascript objects using rust. The rust node contains the reflector which is using to bind the javascript object every time a thing is manipulated on the rust side.

'''Reflector design in dom'''

[[File:Reflector.png]]

The dom_struct is the DOM structure that the ImageBitMap data has from the javascript object. It consists of the following-

1. Reflector - a reflector has the pointer to the required JavaScript object.

2. width and height - the width and the height part of the ImageBitMap's data as mentioned in the webidl file. The required datatype[https://doc.rust-lang.org/book/ch03-02-data-types.html] is 32-bit unsigned integers, denoted by u32.

3. As the imagebitmap needs to be implemented backed b a <Vec8> buffer, as mentioned in the problem statement, the DomRefCell<Vec<u8>> has been used. Where, u8 stands for 8-bit unsigned integer, which is used to hold the data of colour model[https://en.wikipedia.org/wiki/Color_model] and DOMRefCell is the RefCell[https://doc.rust-lang.org/std/cell/struct.RefCell.html] equivalent for the DOM implementation. RefCell is a wrapper used to make the data mutable, which is a required property here as the colour data might be altering.

[[File:rs_dom_struct.PNG]]

The image below shows how this struct is organised

[[File:struct.png]]

Here we implement the code that reads in the various attributes and the javascript objects required (shown below). We use the words '''impl ImageBitmap'''[https://doc.rust-lang.org/std/keyword.impl.html] which means the implementation of the ImageBitmap type. It will be using the '''newinherited''' and the '''new''' methods to obtain the required javascript objects and resolve the intended promises.

'''new_inheritence''' method is where the new instance of the ImageBitmap is created. '''new''' method is where the javascript object is connected to the ImageBitmap object[https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html].

[[File:rs_impl_ibm.PNG]]

Here we implement the code for the getter methods for '''height''' and '''width''' attributes for an ImageBitmap object. We use '''impl ImageBitmapMethods for ImageBitmap''' here which includes only the methods that are required as part of the implementation of the ImageBitmap.

[[File:rs_impl_methods.PNG]]

The height and width attributes are as shown below :

[[File:hw.png]]

The detailed description of the algorithm that has been implemented can be seen in the HTML Standard [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap].

'''Note''': Please note that the implementation does not have detailed comments as we were asked to remove them since they are against the servo implementation guidelines.

=='''How to Setup and Run'''==
The following are the steps to build the servo.

1. git clone the servo repository

2. setup all the pre-requisites[https://github.com/servo/servo/blob/master/README.md#on-windows-msvc]

3. switch into the "servo" directory - cd servo

4. build the project using:

4.1. For Windows

mach.bat build -dev

run the project using:

mach run -d -- https://github.com

4.2. For Linux / Mac-OS

./mach build --dev

run the project using:

./mach run --release tests/html/about-mozilla.html

=='''Test_Plan and Testing'''==

Upon successful completion of the setup and building the whole browser engine. You should get an output that is something similar to the image below.

[[File:Freak2.PNG]]

-> This completes the first step of testing as you will able to successfully run the software.

'''Note''': Please be aware that your system may hang up during the process as it involves compiling the whole code from source and this involves usage of the whole processing power of the local system. Don't fret yet, the system will come back to its normal state after the build is completed.

'''Note''': Time to compile depends on the CPU clock speed, and varies widely.

-> The next part of the testing involves checking for file tidiness, i.e. checking if all standards of the servo have been met.

Running the below command will test for the same.
[FOR LINUX / MAC-OS]

./mach test-tidy
./mach fmt

[FOR WINDOWS]

mach.bat test-tidy
mach.bat fmt

The output should be similar to the below picture which shows that the tests that were passed.

[[File:Freak.PNG]]

-> The next part of testing is the unit-tests

Running the below command will run all unit-tests

./mach test-unit [FOR LINUX / MAC-OS]

mach.bat test-unit [FOR WINDOWS]

'''Note''': The output is too large to include everything here image here but this [https://community-tc.services.mozilla.com/tasks/Zwl0KyYhTCSa6mEQ1QpsNg/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2FZwl0KyYhTCSa6mEQ1QpsNg%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG FILE] has the full details of all the unit-tests passed.

-> Then the next steps involve running the servo-provided automated WPT [Web Platform Tests] that are relevant for our implementation.

I am providing the commands to run the [https://github.com/servo/servo/blob/master/tests/wpt/README.md#running-the-tests WPT tests] on Linux

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html

To save the log results to a file, for example wpt.log

./mach test-wpt tests/wpt/web-platform-tests/html/dom/idlharness.https.html --log-raw wpt_dom.log

Once the test results are saved to the log, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-test-expectations update the test expectations].

./mach update-wpt wpt_dom.log

Now to test another relevant feature for the above implementation and save it to a log file named wpt_interface-objects.log

./mach test-wpt tests/wpt/web-platform-tests/workers/semantics/interface-objects/001.worker.js --log-raw wpt_interface-objects.log

./mach update-wpt wpt_interface-objects.log [ UPDATING TEST EXPECTATIONS ]

'''Note''': The output can also be viewed in this [https://community-tc.services.mozilla.com/tasks/f-RoigFcT3iUzkSg9OunvA/runs/0/logs/https%3A%2F%2Fcommunity-tc.services.mozilla.com%2Fapi%2Fqueue%2Fv1%2Ftask%2Ff-RoigFcT3iUzkSg9OunvA%2Fruns%2F0%2Fartifacts%2Fpublic%2Flogs%2Flive.log LOG_FILE] link.

Now to cap it all off, we need to [https://github.com/servo/servo/blob/master/tests/wpt/README.md#updating-the-wpt-manifest update the WPT manifest] so that all the changes have been registered and reflected appropriately.

It can be done by the command below.

./mach update-manifest

This finishes the testing for the code and you can see that the test coverage has increased.

=='''References'''==

[1] [https://en.wikipedia.org/wiki/Rust_(programming_language) Rust Language Wikipedia]

[2] [https://en.wikipedia.org/wiki/Servo_(software) Servo Software Wikipedia]

[3] [https://www.rust-lang.org/ Rust Language Official Website]

[4] [https://www.slideshare.net/SamsungOSG/how-servo-renders-the-web-52095380 servo working architecture]

[5] [https://doc.rust-lang.org/book/index.html Rust Language Textbook]

[6] [https://developer.mozilla.org/en-US/docs/Web/API/ImageBitmap ImageBitmap API Standard]

[7] [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas Canvas Element]

[8] [https://developers.google.com/web/updates/2016/03/createimagebitmap-in-chrome-50 Bitmap flow]

[9] [https://github.com/servo/servo/wiki/Implement-ImageBitmap-project Implement ImageBitmap problem statement]

[10] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/webidls/ImageBitmap.webidl ImageBitmap WebIDL code]

[12] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap WebIDL Standard]

[13] [https://github.com/SasiDharKM/servo/blob/master/components/script/dom/imagebitmap.rs ImageBitmap Rust code]

[14] [https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html Crates and Packages for Rust]

[14] [https://doc.rust-lang.org/book/ch03-02-data-types.html Data Types in Rust]

[15] [https://en.wikipedia.org/wiki/Color_model Color Model Wikipedia]

[16] [https://doc.rust-lang.org/std/cell/struct.RefCell.html RefCell in Rust]

[17] [https://doc.rust-lang.org/std/keyword.impl.html impl Keyword in Rust]

[18] [https://jeenalee.com/2016/10/03/implementing-doge-for-servo.html Implement a new DOM tutorial]

[19] [https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap ImageBitmap Algorithm]

[20] [https://github.com/servo/servo/pull/26009 ImageBitmap Implementation pull request]

[21] [https://github.com/servo/servo/blob/master/README.md#on-windows-msvc Build Pre-requisites for Rust]

[22] [https://github.com/servo/servo/blob/master/tests/wpt/README.md Testing the Servo Code]