Homework Assignment #2 [40 points + 10 points extra credit]


Overview

In this assignment you enhance the ics432imgapp application so that it’s a bit more informative, so that it doesn’t freeze while computing, and so that one can cancel a running job. Note that doing so can entail pretty extensive software redesign. (The starter application is implemented well, but not necessarily with concurrency in mind. Thankfully it’s not a lot of code!)

In this assignment you have to use GitHub Issues as follows:

How/What to turn in

You should upload to Laulima:


Question #1 [15 pts]: A more informative job window

Create and address the following GitHub issue:

Issue Title: Make the Job window print execution time information

Issue Label: new feature

Issue Description: Once a job has completed, make it so that the job window displays clearly:

Note: You are free to implement the “display” in any way you want, but no need to go fancy. We’re going for clear and correct.

Hint: A clean way to keep track of the above times is to add corresponding variables to the Job class.

TO DO: Using this set of 25 jpg sea urchin images hosted on Laulima run each filter using your application, and report image read times, write times, and processing times in your README file. Do this on an idle computer so that the application does not compete with other applications while it runs. For each filter, compute the ratio of compute time to I/O time (i.e., read time + write time). For instance, if a filter has ratio 10, that means it takes it 10 times longer to process images than to read/write them. We call this ratio the filter’s Compute Intensiveness. Rank the filters in order of decreasing Compute Intensiveness.


Question #2 [25 pts]: Unfreezing the application

Create and address the following GitHub issue:

Issue Title: Make it so that the application does not freeze while processing

Issue Label: bug

Issue Description:

Hint: Most of the above (but for the last item) is done by making sure that the job execution happens in a thread. That is, instead of having the JobWindow class have an executeJob() method, it instead launches a thread that has a run() method that runs (essentially) the code in the executeJob() method.

Hint: This question requires some software re-engineering. Right now, the JobWindow.executeJob() method calls the Job.execute() method and then updates the display. Now those updates have to be performed while the job is executing. A clean design would be to add “update methods” to the JobWindow class, and pass a reference to the JobWindow object to the thread that will execute the job (adding a bunch of getters in JobWindow or making its variables public). The Job class could be modified so that it no longer have an execute() method that processes all images, but perhaps instead a processNextImage() method, that only processes one image and returns an ImgTransformOutcome object. That way, the Job class doesn’t have to know anything about the display. Instead, the thread performing the computation can operate as: process an image, update the display, process another image, update the display, and so on… The expectation is that you consider possible designs and make good choices, like you would have to do throughout your entire professional lives!

Hint: Remember that only the JavaFX Application Thread can update the display, and that the way to do this is to use Platform.runLater(). This is already done for you in the FileListWithViewPort method. But when you update the job window with the timing information (Question #1), that would be done using Platform.runLater(). Note that if you don’t your code will likely work ok, but eventually, these “the wrong thread does a thing” can balloon up into horrible bugs.

Note: Once you’ve done the above, your app must be able to run multiple jobs at the same time!!!


Question #3 [10 pts - EXTRA CREDIT]: Adding a Cancel button to the Job window

Create and address the following GitHub issue:

Issue Title: Add a Cancel button to the Job Window

Issue Label: new feature

Issue Description:

What you need here is the classical “terminate Java threads via deferred cancellation” solution.

Hint: Like the previous one, this question may require some software re-engineering.