element which spans the entire screen. When the mouse is held down, the

listens for mouse input, and calculates the number of pixels that the FractalGrid should be told to move. The FractalOptions class creates the "Options" menu that is shown at the bottom of the screen. It tells the FractalGrid to update when the options are changed. The ZoomControl class creates the zoom buttons that are shown at the top of the screen. It tells the FractalGrid when the buttons are pressed, and listens to FractalGrid for changes in the current zoom level. The KeyCatcher class creates a function to listen for keyboard events. Because Internet Explorer does not have keyboard events on its window object, the 's onmouse- events are used if possible. --- Code Notes --- Box-and-Window algorithm: In order to speed up the rendering of the fractals, I created an algorithm that is able to determine the color of the majority of the pixels without actually testing for them. The algorithm takes advantage of a property of Mandelbrot and Julia fractals that I noticed while working with the application. At any place on the fractal where you could draw a perimeter of a solid color, the area inside that perimeter will also be of that color. The only exception to this rule that I could find was if the perimeter encompasses the entire fractal. Due to the nature of the application, FractalServlet is never asked to draw a complete fractal, it only draws one portion (slice) at a time. When a slice is requested, the Box method traces the perimeter of the slice to see if it is a solid color. If it finds that it is, it fills it with the solid color. If it is not, it sends it to the Window method. The Window method divides the square into four squares and sends each of these squares back to the Box method. By recursing until the box is quite small, the algorithm is able to predict the color of most pixels. This algorithm resulted in a dramatic speed increase of fractal rendering, and works flawlessly on both the Mandelbrot and Julia fractals. To better demonstrate how the box-and-window algorithm works, I added a colormap option called "boxed". The resulting fractal is colored according to which pixels were rendered and which were predicted. The lighter blue shows where pixels did not need to be rendered. The black pixels were rendered individually. Dark blue pixels are the ones used to guess the contents of the box. They are rendered individually as well. It is worth noting that the window shape used by the algorithm is itself a self-similar shape. Since each window is made up of four more windows, each in turn made up of four more windows, etc. with the potential to go on forever, the window shape is self-similar. --- Infinitely Scrollable Image --- The infinitely scrollable image that makes up the fractal is actually a grid of images which are held together in an HTML . As the table is moved, columns and rows are added or removed in order to fill the entire screen without keeping too many rows and columns in memory. --- Browser Testing --- The method used to test the application on each browser was: * Load the Fractal Explorer in the browser and ensure that the page is rendered correctly * Using the mouse, drag the fractal around * Use the keyboard to pan the fractal * Zoom in and out * Try opening and closing the "options" menu * Change the colormap and see if the fractal is updated appropriately * Change the fractal type and update the fractal It can be assumed that if the browser passes all these tests, the application will be fully functional. The "Download Desktop Background" button was not tested, as it was added after the testing was done. --- Security --- webFractal is a Java servlet application which does not access a database, so it is inherently fairly secure. However, some improvements could be made to make it safer for public use. One potential threat to the server would be a denial-of-service attack. Because the server uses a lot of resources to generate an image, and the height and width can be changed through the URL, it would be conceivable for someone to request hundreds of large images in a short time in order to slow down the server. Since the servlet container limits the access to system resources, this would not likely crash the server, but it may make the service unstable for other users. A possible solution to this would be to limit the number of requests per IP address as well as the size of the images requested. --- Known Bugs and Limitations --- * All caching is done on the client-side to save bandwidth when only one user has access to the application. If it were to be set up on a public server, it would be reasonable to cache the images on the server as well to reduce server load from re-rendering the same images. * Not all browsers are supported. * At high zoom levels, the image loses a lot of detail. This is probably due to rounding errors since the numbers being used at those zoom levels are very small. * Due to the high number of requests to the server, some are occasionally dropped (The Tomcat log shows a "socket write error"). This causes an image to not load. The problem can be temporarily fixed by dragging the image outside of the screen and back in. Running the script on a server with more resources should reduce this problem.