I. Simple Display Model-No two objects overlap on the display, so it is
	ok to update an object by erasing its old image and displaying its
	new one

    1. XOR can provide a way to quickly draw feedback objects without
       going through the display manager

    2. Many windowing systems provide a way to specify the color with
       which we wish to draw an xor object against a normal background.
       The system then computes the color that needs to be xor'ed to
       achieve the desired color. Formally, if C is the color than
       C = XOR(D,B) and D is the color the system computes.

    3. xor.java illustrates the
       use of xor in java. The below applet shows xor.java in action. You
       should click on the applet to get the two xor'ed red rectangles to
       appear and disappear. Note that the code specifies that an xor'ed
       rectangle should appear red when drawn over a white background. When
       it is drawn over the black and yellow backgrounds, the resulting
       color is unpredictable.
       

       

II. More Realistic Model-Objects can overlap on the display

        A. Problems with simple erase and redraw

    	    1. If you erase an object's old image, it may erase parts of other
		objects as well
	
	    2. If you redraw an object it will appear on top of all other
		objects--perhaps it should be covered by other objects in
		its new location

	B. Need a more sophisticated algorithm which redraws parts of
		other objects which are erased and draws the object in
		the proper covering order

	C. Solutions

	    1. Redraw all objects using appropriate covering order--too
		expensive when hundreds or thousands of objects

	    2. Only redraw damaged parts of screen--must keep data structures
		that keep track of  damaged objects

III. Incremental Redisplay

    A. Rationale-Updating the whole screen when there are hundreds or thousands
	of objects is too expensive

    B. Definitions

	1. Bounding Box--The small rectangle that encloses a set of objects

    C. Strategy

	1. Keep track of all objects that have a changed visual property,
		such as position, size, color, or stacking order

	    a. As objects are changed, merge their old position into
		an "old" bounding box. This bounding box keeps track
		of the original locations of the changed objects

	2. When an update command is issued

	    a. Compute the new bounding box of the changed objects

	    b. For each displayed object, determine whether the displayed
		object intersects either the new or old bounding box.

		i. Redraw the objects that intersect either the new or
			old bounding box in the appropriate stacking order

	       ii. Only redraw the portion of the object that changes--most
			windowing systems provide a clip region that 
			facilitates redrawing only a portion of the object.

	3. Optimization--For composite objects, check the composite object's
		bounding box before checking its individual children. If the
		composite object doesn't intersect either of the bounding
		boxes, then none of its children can, so none of its children must
		be checked.

	4. Algorithm

	    a. Data structures and Variables

		i. For each window you should maintain the following
			variables

		    a. objs_changed: The set of objects that have changed
		    b. old_bbox: The bounding box for the changed objects'
			old positions
		    c. new_bbox: The bounding box for the changed objects'
			new positions

	    b. Update algorithm

	     -all variables prefixed by self refer to instance variables
	     -if a variable is not prefixed by self then it is a local
	     	variable
		
	     Win::Update()

		new_bbox = empty
		old_bbox = self.old_bbox
		for each obj in self.objs_changed do
		    new_bbox = new_bbox U obj's position
		for each obj in self.children do
		    if intersect(obj, old_bbox) or intersect(obj, new_bbox)
			obj.update(old_bbox, new_bbox)
		self.old_bbox = empty
		     
	     Container::Update(old_bbox, new_bbox)
		
		for each obj in self.children do
		    if intersect(obj, old_bbox) or intersect(obj, new_bbox)
			obj.update(old_bbox, new_bbox)

	     Primitive_Obj::Update(old_bbox, new_bbox)
		self.draw(old_bbox, new_bbox)

	c. Notification algorithm

	    Win::notifyChange(obj)
		self.objs_changed_objs = self.objs_changed U obj
		self.old_bbox = self.old_bbox U obj's position

    D. Java Notes

        1. Java's repaint method merges bounding boxes so you cannot use an old and
	   a new bounding box--you must change the above update procedure so that
	   it uses a single bounding box instead

	2. If you really want to use an old and new bounding box, then call
	   paintImmediately. paintImmediately will immediately queue a paint
	   event rather than aggregating a number of repaint calls and then
	   generating a single paint event. However, you must be careful about
	   calling paintImmediately because if there are several changes to
	   the display, you could end up calling it several times. One scheme
	   that could work with a display manager would be to add a second
	   notification procedure called UpdatesCompleted. UpdatesCompleted
	   would call paintImmediately twice, once with the old bounding box
	   and once with the new bounding box.

IV. Separation of display manager from windows: The previous algorithm
	hard-codes the display algorithm into the window. A better
	approach is to allow display managers to be attached to windows
	so that different display algorithms can be used depending
	on the application.

    A. Interface: Use the observer pattern

		interface DisplayManager {
		  public:
		    void update();
		    void addObject(GraphicalObject);
		    void removeObject(GraphicalObject);
		    void notifyChange(GraphicalObject, PropertyName);
           	 }

    B. Variables: Each window and container should maintain a pointer to
	a display manager object

    C. Methods: 

	    Win::update() 
		displayManager.update();

	    Container::update() 
		displayManger.update();

	    /* Methods for implementing the above display algorithm */
            DisplayManager::Update()
		new_bbox = empty
		old_bbox = self.old_bbox
		for each obj in self.objs_changed do
		    new_bbox = new_bbox U obj's position
		for each obj in registeredObjects do
		    if intersect(obj, old_bbox) or intersect(obj, new_bbox)
			obj.update(old_bbox, new_bbox)
		self.old_bbox = empty
	
V. Quadtrees: Quadtrees provide a way of dividing a region into quadrants.
	Each quadrant contains a list of all the objects that intersect
	its bounding box. Each node of a quadtree has four children, 
	corresponding to a northeast, northwest, southeast, and southwest
	quadrant.

    A. Splitting a quadrant: When the number of objects in a quadrant
	exceeds a threshold, the quadrant is subdivided into four
	quadrants.

    B. Alternative Quadtree implementations:

	1. Only leaf nodes contain a list of objects. Objects can appear
		in multiple leaf nodes if they overlap multiple quadrants.

	2. All nodes contain a list of objects. An object appears in the
		topmost quadrant that is large enough to completely contain
		that object.