6/13/20151 cs 160: lecture 13 professor john canny fall 2004

45
06/20/22 1 CS 160: Lecture 13 Professor John Canny Fall 2004

Post on 19-Dec-2015

217 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 1

CS 160: Lecture 13

Professor John CannyFall 2004

Page 2: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 2

Outline

Model-view controller* Why do we need it?* Changing the display* Event flow* Dragging at interactive speeds

Interactive application programming* Callbacks* Multi-threaded programming

Page 3: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 3

Model-View-Controller

Architecture for interactive apps* introduced by Smalltalk developers at PARC

Partitions application in a way that is* scalable* maintainable

Model

View

Controller

Page 4: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 4

Example Application

Blue circles: 4Cardinal squares: 2

Page 5: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 5

Model

Information the app is trying to manipulate

Representation of real world objects* circuit for a CAD program

+logic gates and wires connecting them

* shapes in a drawing program+geometry and color

ModelView

Controller

Page 6: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 6

View

Implements a visual display of the model

May have multiple views* e.g., shape view and numerical view

ModelView

Controller

Page 7: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 7

Multiple Views

Blue circles: 4Cardinal squares: 2

Page 8: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 8

View

Implements a visual display of the model May have multiple views

* e.g., shape view and numerical view Any time the model is changed, each view

must be notified so that it can change later* e.g., adding a new shape

ModelView

Controller

Page 9: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 9

Controller

Receives all input events from the user Decides what they mean and what to do

* communicates with view to determine which objects are being manipulated (e.g., selection)

* calls model methods to make changes on objects+model makes change and notifies views to update

Model

View

Controller

Page 10: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 10

Controller

Blue circles: 4Cardinal squares: 2

Page 11: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 11

Controller

Blue circles: 4Cardinal squares: 2

Page 12: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 12

Relationship of View & Controller

“pattern of behavior in response to user events (controller issues) is independent of visual geometry (view issues)”

Controller must contact view to interpret what user events mean (e.g., selection)

Page 13: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 13

Combining View & Controller

View and controller are tightly intertwined* lots of communication between the two

Almost always occur in pairs* i.e., for each view, need a separate controller

Many architectures combine into a single class

ModelView

Controller

Page 14: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 14

Why MVC?

Combining MVC into one class or using global variables will not scale* model may have more than one view

+each is different and needs update when model changes

Separation eases maintenance* easy to add a new view later * new model info may be needed, but old views

still work* can change a view later, e.g., draw shapes in 3-

d (recall, view handles selection)

Page 15: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 15

Presentations next Mon-Weds

Monday groups 1-5 Weds groups 6-10

Page 16: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 16

Adding Views Later

Blue circles: 4Cardinal squares: 2

Page 17: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 17

Changing the Display

How do we redraw when shape moves?

Page 18: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 18

Moving Cardinal Square

Blue circles: 4Cardinal squares: 2

Page 19: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 19

Erase w/ Background Color and Redraw

Blue circles: 4Cardinal squares: 2

Page 20: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 20

Changing the Display

Erase and redraw* using background color to erase fails* drawing shape in new position loses ordering

Move in model and then redraw view* change position of shapes in model* model keeps shapes in a desired order* tell all views to redraw themselves in order* slow for large / complex drawings

+flashing!

Page 21: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 21

Damage / Redraw Method

View informs windowing system of areas that need to be updated (i.e., damaged)* does not redraw them at this time…

Windowing system* batches updates* clips them to visible portions of window

Next time waiting for input* windowing system calls Redraw method for

win.+passes region that needs to be updated

Page 22: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 22

Damage old, Change position in model, Damage new

Blue circles: 4Cardinal squares: 2

Page 23: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 23

Event Flow

Creating a new shape

Page 24: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 24

Event Flow (cont.)

Assume blue circle selected

Blue circles: 0Cardinal squares: 0

Page 25: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 25

Event Flow (cont.)

Press mouse over tentative position Windowing system identifies proper window for event Controller for drawing area gets mouse click event Checks mode and sees “circle” Calls models AddCircle method with new position

Blue circles: 0Cardinal squares: 0

Page 26: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 26

Event Flow (cont.)

AddCircle adds new circle to model’s list of objects Model then notifies list of views of change

* drawing area view and text summary view

Views notifies windowing system of damage* both views notify WS without making changes yet!

+model may override

Blue circles: 0Cardinal squares: 0

Page 27: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 27

Event Flow (cont.)

Views return to model, which returns to controller Controller returns to event handler Event handler notices damage requests pending and

responds If one of the views was obscured, it would be ignored

Blue circles: 0Cardinal squares: 0

Page 28: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 28

Event Flow (cont.)

Event handler calls view’s Redraw methods with damaged area

Views redraw all objects in model that are in damaged area

Blue circles: 1Cardinal squares: 0

Page 29: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 29

Dragging at Interactive Speeds

Damage old, move, damage new method may be too slow * must take less than 200 ms to be smooth

Solutions* don’t draw object, draw an outline (cartoon)

+use XOR to erase fast (problems w/ color)+save portion of frame buffer before dragging

Page 30: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 30

Break

Next week presentations: Monday: groups 1-5 Wednesday: groups 6-10

Page 31: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 31

Interactive programming

Callbacks Threading

Page 32: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 32

Callbacks Callbacks: every widget registers itself

to receive certain events with the OS. Dangers: UI code using callbacks is

usually single-threaded. Control does not return to the event loop until the callback returns. Therefore in a callback routine, never:* Wait for another event.* Sleep.* Perform I/O or other actions that may block.

Page 33: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 33

HE Principles: User control and freedom Visibility of system status Help, diagnosing errors

Page 34: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 34

Threaded code Multi-threaded code uses distinct

threads for distinct widgets. It allows blocking operations (e.g. I/O) to

be confined to particular threads that don’t affect interactivity.

If your program has any time-intensive parts, they should run in different threads from the UI code.

Page 35: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 35

Threaded code Use separate threads for any operations

that can occur asynchronously:* UI interactions.* File operations – use separate threads if you

need to be updating several files at the same time.

* Inter-process communication (sockets): use one thread for each connection.

* Use a thread for each other I/O device, e.g. one each for reading from or writing to the sound card.

Page 36: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 36

Inter-thread communication The window system and running process

in the OS communicate using message passing:* The event queue and sockets are examples of

message-passing primitives.

Processes in the same address space (i.e. within your program) can use shared memory (i.e. shared variables) which is much more efficient.

Page 37: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 37

Inter-thread communication Why can’t thread A call thread B (like a

callback?)

Page 38: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 38

Synchronization Shared-memory communication poses

challenges. If you rely on “mailbox” primitives, things can go wrong:

<blank>0

Flag to show this threadis writing new data

Data

Page 39: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 39

Synchronization

Intuitively, threads that want to write should:….

wait until thread_id = 0;

write thread_id;

write data;

<blank>0

Data

Flag to show this threadis writing new data

Page 40: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 40

Synchronization

But thread switching can happen anytime, e.g.

….

wait until thread_id = 0;

write thread_id;

write data;

<blank>0

Data

Flag to show this threadis writing new data

Page 41: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 41

Synchronization

A switch between checking the flag and setting it allows both threads to (incorrectly) write the flag and their data. To prevent this, we define critical sections of the code that cannot be interrupted.

<blank>0

Data

Flag to show this threadis writing new data

Page 42: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 42

Synchronization

e.g. the critical section in the example is:….

wait until thread_id = 0;

write thread_id;

write data;

<blank>0

Data

Critical section, thread can’t be pre-empted.

Flag to show this threadis writing new data

Page 43: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 43

Semaphores

Rather than many critical sections in your code, you can use a single semaphore primitive.

A semaphore is initialized to an integer n, and has just two operations:test(); wait until semaphore > 0, then decrement it.

increment(); increment the semaphore.

Page 44: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 44

Semaphore example

Then the example code becomes (with sem1 initialized to 1):….

sem1.test();

write thread_id;

write data;

sem1.increment();

This section cannot bepre-empted by the other

process that is using this semaphore.

Page 45: 6/13/20151 CS 160: Lecture 13 Professor John Canny Fall 2004

04/18/23 45

Summary

Model-view controller* Why do we need it?* Changing the display* Event flow* Dragging at interactive speeds

Interactive application programming* Callbacks* Multi-threaded programming