Post 4: The Frontend Phase

I shall be elaborating on the Frontend of the project in this post, now that we have the backend rolling (a little bit of testing remains, though). For the backend, I embedded an altogether new function “getReportsForSubprocesses” that takes in a memory reporter callback pointer and calculates the RSS and USS for the content processes. In order to integrate it with the frontend, so that the table in the GUI for about:performance populates and updates itself with these reports, we need to modify the Javascript and xhtml files for about:performance to include the required functionality.

For this, we introduced a new object called “SubProcessMonitor” in the javascript that primarily does two important things:

Number 1 :                                                                                                       It gets a handle over nsIMemoryReporter.cpp and calls our newly defined “getReportsForSubprocesses” function by passing in a callback function as argument. The callback function gets converted to a nsIMemoryReporter Callback pointer and XPCOM takes care of this. We have a “getReports” function inside SubProcessMonitor  that returns the resultant values calculated by the backend function in the form of a javascript object. We’ve used a map data structure object for this javascript object called “result”,  with the key for the map being the “pid” of the process and the description of the callback (“RSS/USS”) for populating the table .

Number 2:                                                                                                       It updates the table as defined by a unique identifier in the xhtml file using an “updateTable” function inside SubProcessMonitor. This function does the important job of adding a row to the table for every new pid that it encounters in the “results” object returned by “getReports”. It then populates this row with the corresponding memory values. It also updates the table regularly.

The “go()” function called in the body of aboutperformance.xhtml and defined in the javascript file does the job of loading all the components, when the user loads the about:performance page in the browser. We call the initialization function of the SubProcessMonitor function described above in “go”, so that it further calls “getReports” and “updateTable” to keep updating the Subprocess-performance table.

Once we have the table updating successfully, we’ll be styling it using CSS and this would have our tool all ready!