Introduction to Computer Graphics by np6KJuHl


									                         Event Driven Computing

• Basic Interaction Handling
   – Interactive programs - must pay attention to the user interface          480/580 Lecture 2             Slide 1
                          Human Factors
1) Provide simple and consistent interaction sequences
         eg. each window has same mouse button functions
2) Don't overload user with options - KISS
3) Show available options clearly at every stage of
         Don't expect user to remember
         Place info accessibly but not so it interferes with advanced user
4) Give feedback to user
         Examples in your window manager? - highlights, key echos
5) Allow user to recover gracefully from mistakes
         Allow for arbitrary input
         Cancel, undo             480/580 Lecture 2                       Slide 2
                      Logical Input Devices

• Used by graphics packages to provide device-
  independent code
• Locator - specify screen coordinates and maybe
  some state buttons
• Keyboard - alphanumeric input
• many others          480/580 Lecture 2   Slide 3
                  Event Driven Computing
 How different from programming with simple user
   input and an emphasis on internal computations?
 Example A:
       Read array of integers,
       Sort them, largest first,
       Print the sorted array.
 Example B (ATM machine):
       W: wait for signal that card has been inserted,
          Take care of transaction,
          Go to W.          480/580 Lecture 2           Slide 4
• In A the program determines the sequence of
• In B the users largely determine the sequence
• B is an example of interrupt driven computing
    – An “Interrupt” is the signal that is produced when a
      physical even is sensed by one of the peripherals of a
    – What are the possible interrupts for the ATM machine?
• Example Interrupt Driven Computing (ATM):
    – If an interrupt occurs
          • call interrupt_handler (kind_of_interrupt).
    – Repeat above.              480/580 Lecture 2        Slide 5
• Programs with Graphical User Interfaces require
  interrupt driven computing
     – Not because of the geometric aspects of the display and
       pictures, etc
     – But because the program has to wait for signals from
       the user and execute the appropriate action for each
       signal received       480/580 Lecture 2               Slide 6
• Programs running under operating systems such as Unix
  cannot directly sense physical interrupts
• What part of the system handles interrupts?
• Operating system can pass info about interrupts to
  program in two different ways
   – signal the program immediately
       • program samples or polls a logical input device looking for state changes
       • continuous sampling required by the application program
   – store the info in a place that the application program can check it
       • In window systems the structures containing information about physical
         interrupts are called “events”
       • place stored called “event queue”
       • event driven computing            480/580 Lecture 2                     Slide 7
• Events are more general than interrupts
   – can be used to pass info about things that are not physical
• Events are associated with “event-triggers”
   – a user action that causes an event to occur       480/580 Lecture 2                Slide 8
• Example: Event Handling Program:
   – Check whether an event has occurred
         • and it if has, then call event_handler(kind_of_event)
   – Repeat above
• Compare to Interrupt Driven Computing (ATM):
   – If an interrupt occurs
         • call interrupt_handler(kind_of_interrupt)
   – Repeat above.
• Appear similar - big difference if program has to perform
  significant other computations
   – interrupt driven jumps from current computation to service
     interrupt when it occurs
   – event driven doesn’t notice event until it checks for it
         • problem of user feedback - type-ahead versus draw-ahead             480/580 Lecture 2                   Slide 9

• Standard programming versus interaction based
• Sampling (Polling) versus Event handling of
• Interrupt-driven versus Event-driven   480/580 Lecture 2       Slide 10
 Two programming styles for event handling
• Response to same event needs to differ at times
   – what are the input devices on an ATM?
   – Eg. ATM
         • typing in PIN number, typing in withdrawal amount, etc.
• Nested event handlers
         • only one sequence of accepted events valid
         • infinite wait loops inserted were needed
         • code dealing with events spread throughout so harder to make
           portable between window systems
• State variables
         •   only one sequence of accepted events valid
         •   only one wait loop
         •   code dealing with events in one place - easier to make portable
         •   encourages modular programming              480/580 Lecture 2                     Slide 11   480/580 Lecture 2   Slide 12   480/580 Lecture 2   Slide 13

To top