Netflix Ex. L015 ~
`
`(cid:49)(cid:72)(cid:87)(cid:73)(cid:79)(cid:76)(cid:91)(cid:3)(cid:89)(cid:17)(cid:3)(cid:42)(cid:82)(cid:55)(cid:57)(cid:3)
`Netflix v. GoTV
`(cid:44)(cid:51)(cid:53)(cid:21)(cid:19)(cid:21)(cid:22)(cid:16)(cid:19)(cid:19)(cid:26)(cid:24)(cid:26)(cid:3)
`IPR2023-00757
`(cid:49)(cid:72)(cid:87)(cid:73)(cid:79)(cid:76)(cid:91)(cid:3)(cid:40)(cid:91)(cid:17)(cid:3)(cid:20)(cid:19)(cid:20)(cid:24)
`
`
`
`

`

`Developing
`UserIntertaces
`
`
`
`
`
`
`
`Dan R.Olsen,Jr.
`Carnegie Mellon University/Brigham Young University
`
`Mi r<
`MORGAN KAUFMANN PUBLISHERS, INC.
`San Francisco, California
`
`

`

`
`
`- hae]B.Morgan
`
`
`Sponsoring Editor ieer
`production Manager=Yome tt
`
`production Editor
`pies refiner Alati
`
`Editorial Coordinator Mari yn
`+
`
`eff Van Buere
`Paypeal
`Side by ps sepcige
`
`
`Illustration
`ens aK
`Composition
`Nancy ! Og tien
`
`Cover Design
`Ross Carron Des en
`Proofreaders
`Erin Milnes, Gary
`
`Indexer
`Steve Rath
`
`Printer
`Courier Corporation
`
`
`
`
`
`
`
`
`.
`Morris
`
`Morgan KaufmannPublishers,Inc.
`Editorial and Sales Office:
`340 Pine Street, Sixth Floor
`San Francisco, CA 94104-3205
`USA
`
`415/392-2665
`Telephone
`415/982-2665
`Facsimile
`mkp@mkp.com
`Email
`http://www.mkp.com
`WWW
`Ordertoll free 800/745-7323
`
`©1998 Morgan KaufmannPublishers,Inc.
`All rights reserved
`Printed in the United States of America
`
`02
`
`01
`
`00
`
`99
`
`98
`
`vendo)
`
`2
`
`Pall
`
`Nopartof this publication may be reproduced, storedin a retrieval system,or transmitted in any
`form or by any means—electronic, mechanical, photocopying, recording, or otherwise—without
`the prior written permissionof the publisher.
`
`
`
`
`
`
`
`
`
`
`Library of Congress Cataloging-in-Publication Data
`Olsen, Dan R., 1953-
`
`Developing user interfaces/Dan R, Olsen,Jr.
`
`p. cm.
`
`ISBN 1-55860-418-9
`1. Userinterfaces (Computer s
`CACO: Pp
`ystems) 2. Computer software—Development. I. Title.
`
`
`
`005.4’28--dce2] 97-45231
`
`

`

`
`
`
`
`Contents
`
`
`
`XV
`
`1 1 1 2 2
`
`, 3 4 4 5 6
`
`ll
`
`eeelyun
`
`heOo
`
`25
`
`25
`
`26
`26
`27
`
`Preface
`
`Chapter 1
`
`Introduction
`
`1.1
`
`12
`
`What This BookIs About
`1.1.1
`Early Computing
`1.1.2 Winds of Change
`1.1.3
`The Legacy of Lab Coats
`1.1.4 A Question of Control
`Setting the Context
`1.2.1
`Computer Graphics
`1.2.2
`HumanFactors and Usability
`1.2.3 Object-Oriented Software
`1.2.4 Commercial Tools
`
`1.3
`
`1.4
`
`An Overview of the UserInterface
`1.3.1
`The Interactive Cycle
`1.3.2
`The Interactive Porthole
`1.3.3
`The Interface Design Process
`Summary
`
`Chapter 2
`
`2.1
`
`Designing the Functional Model
`Examples of Task-Oriented Functional Design
`
`2.1.3 Why DoSecretaries Have Typewriters?
`
`vi
`
`
`
`

`

`
`
`CONTENTS
`
`2..2,
`
`2.3
`
`2.4
`
`ee
`
`2.6
`
`Overall Approach
`9.2.1
`Task Analysis
`2.2.2
`Evaluation of the Analysis
`2.2.3
`Functional Design
`Task Analysis
`2.3.1
`Examples of Task Analysis
`2.3.2
`VCR Task Analysis
`2.3.3
`Student Registration Task Analysis
`Evaluationof the Analysis
`2.4.1 Understanding the User
`2.4.2 Goals
`2.4.3
`Scenarios
`2.4.4
`Programmers and User Interface Design
`Functional Design
`2.5.1 Assignment of Agency
`2.5.2 Object-Oriented Functional Design
`Summary
`
`Chapter3
`
`3.1
`
`3.2
`
`3.3
`
`3.4
`
`3.5
`
`Basic Computer Graphics
`Models for Images
`3.1.1
`Stroke Model
`3.1.2
`Pixel Model
`3.1.3
`Region Model
`Coordinate Systems
`3.2.1 Device Coordinates
`3.2.2
`Physical Coordinates
`3.2.3 Model Coordinates
`3.2.4
`Interactive Coordinates
`HumanVisual Properties
`3.3.1 Update Rates
`Graphics Hardware
`3.4.1
`Frame Buffer Architecture
`3.4.2 Cathode Ray Tube
`3.4.3
`Liquid Crystal Display
`3.4.4 Hardcopy Devices
`Abstract Canvas Class
`
`
`
`3.5.1 Methods and Properties
`
`

`

`
`
`viii
` » CONTENTS
`
`3.8
`
`3.9
`
`3.6 Drawing
`3.6.1
`Paths
`3.6.2
`Closed Shapes
`3.7 Text
`Font Selection
`3.7.1
`Font Information
`3.7.2
`3.7.3 Drawing Text
`3.7.4 Outline vs. Bitmapped Fonts
`3.7.5 Character Selection
`3.7.6
`Complex Strings
`Clipping
`3.8.1
`Regions
`Color
`3.9.1 Models for Representing Color
`3.9.2 Human ColorSensitivity
`Summary
`
`3.10
`
`Chapter 4
`
`4.1
`
`4.2
`
`4.3
`
`4.4
`
`Basics of Event Handling
`Windowing System
`4.1.1
`Software View of the Windowing System
`4.1.2 Window Management
`4.1.3 Variations on the Windowing System Model
`4.1.4 Windowing Summary
`Window Events
`4.2.1
`Input Events
`4.2.2 WindowingEvents
`4.2.3
`Redrawing
`The Main Event Loop
`4.3.1
`Event Queues
`4.3.2
`Filtering Input Events
`4.3.3 Howto Quit
`4.3.4 Object-Oriented Modelsof the
`Event Dispatching and Handling
`4.4.1 Dispatching Events
`4.4.2
`Simple Event Handling
`4.4.3 Object-Oriented Event Handling
`
`Event Loop
`
`104
`
`105
`
`106
`106
`108
`108
`
`109
`
`111
`112
`117
`
`
`
`

`

`4.5 Communication between Objects
`4.5.1
`Simple Callback Model
`;
`,
`4.5.2,
`Parent Notification Model
`4.5.3 Object Connections Model
`Summary
`
`4.6
`
`CONTENTS
`
`"
`
`121122
`124
`oe
`126
`
`
`
`Chapter5 Basic Interaction
`5.1
`Introduction to Basic Interaction
`5.1.1
`Functional Model
`5.2 Model-View-Controller Architecture
`5.2.1
`The Problem with Multiple Parts
`5.2.2. Changing the Display
`5.2.3 General Event Flow
`5.3 Model Implementation
`5.3.1
`Circuit Class
`5.3.2 CircuitView Class
`5.3.3
`View Notification in the Circuit Class
`5.3.4 Overview of the Circuit Class
`5.4 View/Controller Implementation
`5.4.1
`PartListView Class
`5.4.2
`LayoutView Class
`5.5 Review of Important Concepts
`5.5.1
`Functional Model
`5.5.2 View Notification
`5.5.3 View Implementation
`5.6 AnAlternative Implementation
`5.7 Visual C++
`5.7.1
`CView
`5.7.2 CDocument
`Summary
`
`5.8
`
`Chapter 6 Widget Tool Kits
`6.1 Model-View-Controller
`6.1.1 Widget Models
`6.1.2
`Independenceof View and Controller
`
`170
`
`129
`129
`130
`132
`134
`135
`138
`143
`143
`144
`145
`146
`147
`147
`152
`161
`161
`161
`162
`163
`164
`164
`165
`166
`
`167
`167
`168
`
`

`

`
`
`179
`173
`174
`175
`\75
`\76
`
`\77
`177
`185
`186
`189
`19]
`193
`193
`
`194
`
`195
`
`195
`
`197
`
`198
`
`198
`201
`
`201
`
`202
`203
`204
`205
`
`210
`
`211
`
`213
`
`215
`
`215
`
`
`ook
`e Look Must Present
`; What th
`f Screen Space
`Economy °
`‘19
`oe Consistent
`Look
`| Issues 1n
`itectura
`6.4.4 Architec
`4SeptAlphabet ofInteractiveBehaviors
`6.5.2
`Perceived Safety
`Summary
`
`Designing the Look
`
`6.5
`
`6.6
`
`
`
`
`
`
`
`
`
`
`
`Chapter8
`
`8.]
`
`Chapter7
`7.1
`
`7.2
`
`73
`
`7.4
`
`fan
`
`Interfaces from Widgets
`Data-Driven Widget Implementations
`7.1.1 Collections of Widgets
`Specifying Resources
`7.2.1
`Resource Organizations
`7.2.2
`Interface Design Tools
`Layout
`Fixed-Position Layout
`7.3.1
`Struts and Springs
`73.2
`Intrinsic Size
`7.3.3
`7.3.4 Variable Intrinsic Size
`Communication
`74.1
`Parent Notification
`Summary
`
`
`
`
`
`
`
`
`
`
`
`Input Syntax
`Ee Description Languages
`
`1.1
`elds and Conditions
`
`aePecial Types of Fields and Conditions
`
`216
`
`

`

`Productions
`
`Input Sequences
`
`8.1.3
`8.1.4
`8.2 Buttons
`Check Buttons
`8.2.1
`Scroll Bars
`8.3
`8.4 Menus
`8.5
`Text Box
`8.6
`From Specification to Implementation
`8.6.1
`Fields
`8.6.2
`Productions
`Summary
`
`8.7
`
`9.3
`
`Chapter9 Geometry of Shapes
`9.1 The Geometry ofInteracting with Shapes
`9.1.1
`Scan Conversion
`9.1.2. Distance from a Point to an Object
`9.1.3
`Bounds of an Object
`9.1.4 Nearest Point on an Object
`9.1.5
`Intersections
`9.1.6
`Inside/Outside
`9.2 Geometric Equations
`9.2.1
`Implicit Equations
`9.2.2
`Parametric Equations
`Path-Defined Shapes
`9.3.1
`Lines
`9.3.2 Circles
`9°35.
`AICS
`9.3.4
` Ellipses and Elliptical Arcs
`9.3.5
`Curves
`9.3.6
`Piecewise Path Objects
`Filled Shapes
`9.4.1
`Rectangles
`9.4.2 Circles and Ellipses
`9.4.3
`Pie Shapes
`9.4.4 Boundary-Defined Shapes
`Summary
`
`9.4
`
`9.5
`
`CONTENTS
`
`xi
`
`*
`
`2
`2:20
`222
`225
`230
`234
`237
`238
`242
`248
`
`280
`
`249
`250
`251
`251
`252
`252
`253
`253
`253
`253
`254
`255
`255
`258
`261
`264
`266
`274
`974
`974
`276
`277
`277
`
`

`

`
`
`xii
`
`» CONTENTs
`
`Chapter
`
`10
`
`10,
`
`1
`
`G
`:
`Geometric Transformations
`The ThreeBasic Transformation 8
`10.1.1 Translation
`10.1.2 Scaling
`10.1.3. Rotation
`10.1.4 Combinations
`10.2 Homogeneous Coordinates
`e
`10.2.1
`Introductio
`n
`i
`to the Homogeneous Coordinate
`TOS Concatenation
`10.2.3 Vectors
`10.2.4 Inverse Transformations
`obo ees aboutan Arbitrary Point
`
`10.3
`
`10.4
`
`10.5
`
`10.6
`
`ree-Point Transformation
`A Viewing Transformation
`10.3.1 Effects of Windowing
`10.3.2 Alternative Controls of Viewing
`Hierarchical Models
`10.4.1 Standard Scale, Rotate, Translate Sequence
`Transformations and the Canvas
`10.5.1 Manipulating the Current Transformation
`10.5.2 Modeling with Display Procedures
`Summary
`
`11.1
`
`11.2
`
`11.3
`
`Chapter 11 Interacting with Geometry
`Input Coordinates
`Object Control Points
`Creating Objects
`11.3.1 Line Paths
`11.3.2 Splines
`11.3.3 Polygons
`Manipulating Objects
`11.4.1 Selection and Dragging
`11.4.2 General Control Point Dragging Dialog
`Transforming Objects
`11.5.1 Transformable Representationsof Shapes
`11.5.2.
`Interactive Specification of the Basic
`Transformations
`11.5.3 Snapping
`
`11.4
`
`11:9
`
`Ss
`
`281
`
`281
`
`282
`282
`283
`284
`
`285
`
`2.86
`287
`288
`288
`289
`290
`
`290
`
`292
`293
`
`294
`
`295
`
`295
`
`296
`298
`
`300
`
`301
`
`301
`
`303
`
`304
`
`306
`309
`309
`
`310
`
`310
`313
`
`315
`
`315
`
`317
`323
`
`
`
`

`

`
`
`CONTENTS
`
`
`
`
`11.6 Grouping Objects
`11.6.1 Selection in a Hierarchical Model
`11.6.2. Level of Interaction ina Hierarchy
`Summary
`
`11.7
`
`12.2
`
`Chapter 12 Drawing Architectures
`Basic DrawingInterface
`12.1
`Interface Architecture
`12.2.1 Draw-Area Architecture
`12.2.2 Palette Architecture
`12.2.3 Summary of Architecture
`12.3 Tasks
`12.3.1 Redrawing
`12.3.2 Creating a New Object
`12.3.3 Selecting Objects
`12.3.4 Dragging Objects
`12.3.5 Setting Attributes
`12.3.6 Manipulating Control Points
`Summary
`
`12.4
`
`Chapter 13 Cut, Copy, and Paste
`13.1 Clipboards
`13.1.1 Simple Clipboard
`Publish and Subscribe
`13.2
`13.3 Embedded Editing
`13.3.1 Embedded Pasting
`13.3.2 Edit Aside
`13.3.3 Edit in Place
`
`13.4
`
`Summary
`
`Chapter 14 Monitoring the Interface: Undo, Groupware,
`and Macros
`
`14.1
`
`Undo/Redo
`14.1.1 Simple History Architecture
`14.1.2 Selective Undo
`14.1.3 Hierarchical Undo
`14.1.4 Review of Undo Architectural Needs
`
`324
`326
`327
`
`328
`
`331
`
`331
`
`334
`
`- 336
`342,
`345
`
`346
`
`346
`347
`349
`350
`352,
`353
`
`354
`
`357
`
`358
`
`359
`
`364
`
`367
`
`368
`370
`370
`
`371
`
`373
`
`374
`
`375
`376
`377
`378
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`
`
`xiv
`s CONTENTS
`
`14.2
`
`14.3
`
`14.4
`
`Groupware
`14.2.1 Asynchronous Group Work
`14.2.2 Synchronous Group Work
`14.2.3 Groupware Architectural Issues
`Macros
`
`Monitoring Architecture
`14.4.1 Command Objects
`14.4.2 Extended CommandObjects
`
`14.5
`
`Summary
`
`Endnotes
`
`Index
`
`378
`
`378
`380
`380
`
`381
`
`383
`383
`389
`
`391
`
`393
`
`397
`
`
`
`

`

`Basic Computer
`Graphics
`
`He completed a functional design of what our user
`
`interactive software.
`
`interface is to accomplish and howitis logically struc-
`tured, we mustlay the technical groundwork required
`for implementing graphical presentations. This chapter covers the basics of
`2D computergraphics, involving the basic drawing techniques and hardware.
`Also included is the necessary 2D geometry required for interaction with
`primitive forms. Wealso discussthe issuesof text, clipping a drawing to stay
`within a particular region, andcolor.
`In this chapter, we focuson the basic 2D primitives that are required to pre-
`sent information to the users so they can interactively manipulate it. The
`field of computergraphicsis quite diverse, and only thebareessentials are pre-
`sentedhere.In creating realistic images of physical objects, we must consider
`3D perspective viewing, realistic reflection of light and shadow,texturing
`physical objects, and removing hidden surfaces. The whole area ofrealistic
`physical models as well as the animation of such models is not considered
`here. A variety of computergraphicstexts already address these issues.
`In addition to ignoring high-level 3D modeling and rendering, wealso
`ignore scan conversion. Scan conversion is the process of converting a geo-
`metric shape suchasa line or polygonintoasetof pixels that represent the
`shape on the screen or a printer. Weassumethat any userinterface tool kit
`will provide methodsor procedures that perform such tasks for us.
`In this chapter, we assume that we are using a graphics package thatcan
`draw a variety of 2D shapes, given the appropriate inputs. Our problem is to
`understand howto invoke such methods and how to organize them in a way
`that will efficiently display our user's information. Understanding the various
`display architectures will help us understand how thosearchitecturesaffect
`
`

`

`
`
`52
`»
`
`<
`
`RASIC compuTeé®
`
`GF
`
`aPHICS
`
`5) (9, 7) thick v 2)
`3
`k
`Line (4,
`Line (4, 10) (4, 17) thie ick 3)
`Circle (19, 8) radius di
`
`stroke representation of images
`Figure 3-1
`5
`3.1 Models for Images
`se
`pri
`to
`re resent 2D images—Stto es, pixels, and
`aePe ways to
`af - arehelpful for display, modeling,or
`
`nd each hasit
`
`There are tl
`regions. Eac
`interaction, 4
`3.1.1 Stroke Model
`epresenting geometric objects
`e modelis the earliest form used for F
`odel, we describe all images as strokesof somespeci
`-1 showsa simple diagram ee
`The strok
`fied color and thickness. For example, Figure
`in a comput
`its accompanying stroke representation.
`In the strokerepresentation, the type of stroke and its geometry arere
`refreshdisplays anddirect-view storagetubesreuena
`control hardware was requiredto he
`sented. Early vector
`their images in this fashion. Special
`late the stroke representation into images On the screen. Plotters acceptsuch
`representations and convert them into paths thatthepenshouldcolts
`draw the stroke onpaper. PostScriptprinters also accept suchaepee
`tion, whichtheythenconverttoaregionmodelandthentoapixelmodelin
`sed for many interactive
`actual printing.
`The stroke modelis the one thatis commonly u
`ce tool kits provide mort
`applications. Most graphics packages in user interfa
`iptical arcs, rectangles
`complex stroked objects, including arcs, ellipses, ell
`with rounded corners, and various curved shapes.
`
`er. In this ™
`
`3.1.2 Pixel Model
`The stroke model, however, 1s not adequate for representingmoreTybil
`complex images, such as Figure 3-2. Such images req)
`
`
`

`

`
`
`
`
`MODELS FOR IMAGES
`
`AL
`
`
`
`
`
`
`divides the image into a discrete numberof pixels and then stores an intensity
`or color value for each pixel. In addition,all of today’s graphics hardware is
`pixel based, which meansthat ultimately all models must be reduced to pix-
`els before printing or display.
`There are three key aspects to the resolution of a pixel image. The number
`of rowsof pixels and the numberofpixels per row constitute the spatial reso-
`lution of the image. For good display screens, this is 1024x768, with somedis-
`plays going higher. For most laser printers,
`the resolution varies from
`3000x2400 to 6000x4800 in order to create a high-quality printed page. The
`third aspect is the image depth or numberofbits required to represent each
`pixel.There are four basic forms of pixel-based images. Thefirst is a simple
`bitmap, where each pixel consists of one bit that is either on or off. Such a
`model is suitable for representing the black and white of a printed page. In
`orderto represent levels of gray, several pixels are grouped togetherin various
`patterns of on and off, producing an appearance of grayness. This is the
`approachusedin laser printers, which can either put down a spotof ink or not.
`With very high resolution, this halftoning or dithering process can produce
`acceptablegray.
`In the second method, gray-scale images provide more than1bitper pixel.
`Some systemssuchastheearly NeXTprovided2 bits per pixel. This approach
`only doubled the space required to store the screen image while providing four
`levels of gray. This 2-bit image only marginally improved the quality of pho-
`tographs and other realistic images, but it significantly improved the appear-
`ance of interface items such as buttons and type-in boxes. Items that the
`Macintosh (using bitmaps) had to represent as grainy patterns appeared
`smooth on the NeXT. Most modern gray-scale systemsprovide8 bits (1 byte)
`per pixel, which can represent 956 levels of gray ranging from 0 (black} to 255
`(white). A 1024x1024 gray-scale image requires | megabyteof storage.
`
`

`

`
`
`BASIC COMPUTER GRA
`
`PHICS
`
`»
`
`3.
`
`
`
`Figure 3-3
`
`Pixel representation of a line
`
`A
`
`on of ima
`
`;
`i
`full-color rep-
`aeaes Braeeacea:
`The third, and mostflexible, representati
`resentation. Colors are assembled from the three ad eeeee Pcconcol.
`green, and blue. With8bits per primarycolor(3 bypealyi Seenca tora
`ors can be represented. Such an image format r ae StereShiy teal:
`1024x1024 image. Space becomesa problemwhen
`Sab
`tic full-color images. For photograph-quality images that are 3000
`)
`approximately 22 MBof storage are required. Because of these requirements,
`compression techniquesare often used.
`Thefourth representation is the color-mapped image. In this case, only 8
`bits are used per pixel. Instead of storing a color, each pixel stores an index
`into a color table that contains the full 24 bits for each indexed color. This
`allows manycolor images to be represented in the same space as a gray-scale
`image. Manycolordisplays that are being used for normalinteraction, rather
`than photograph-quality applications, are based on the lookup-table image
`model. In addition to cutting the storage spaceto a third, the smaller number
`of bytes also reduces the amount of computation required to manipulate the
`pixels.
`Although the pixel model can represent any image, there are some prob-
`lems when converting strokeor region objectsinto pixels.If the spatial resolu-
`tion of thepixel Image is low, as shown in Figure 3-3, aliasing can occur where
`smoothobjects, such as a line, appearjagged.
`
`
`
`

`

`
`
`
`Figure 3-4 Antialiasedline
`
`Figure 3-5 Region-based image
`
`
`
`3.1.3 Region Model
`The third image modelis the region model.In this model, stroke objects are
`used to outline the regionto befilled, as shown in Figure 3-5. There are vari-
`ous models by whichregionsarefilled, including constant colors or various
`blendings to produce shaded effects. A major advantage of region models is
`that filled shapes can be represented in very little memory and in a way that
`is independentof the display resolution. This is very advantageousfor high-
`resolution display devices, such as laser printers, where transferring a full page
`to the printer would requireat least 2, MBin pixel form (thus slowing commu-
`nications) and would require that the computer software be aware of the
`printer’s resolution.
`das regions and then converted to bitmapsinside of
`Even text is represente
`od clear text of any size to be generated. In
`the printer; this method allows go
`
`

`

`
`
`56
`«
`
`3
`
`;
`BASIC COMPUTER GRAPHICS
`
`,
`
`y
`
`Origin at the center
`
`Origin at lowerleft
`Figure 3-6 Normal Cartesian coordinates
`
`t be converted to a region
`:
`fact, even a line that is 1 pixel wide o ae ca oer ona
`ter. Otherwise
`Bee
`of pixels when rendered on a 600-dpi
`the line would be too thin in print.
`
`mus
`
`3.2 Coordinate Systems
`An importantconsideration in drawingobjectsis the coordinate system of the
`drawing and the coordinate system in which the objects are defined in the
`application. These coordinate systems may not be the same; this merits care-
`ful discussion
`
`3.2.1 Device Coordinates
`Device coordinates are the coordinatesof the actual display device. In most
`Bene texts, ae origin of the coordinate system is either in the lowerleft
`or
`the center with positive x going to the right and positive
`i
`shownin Figure 3-6.
`3
`nae rE
`eli ereranate system is rarely usedfor frame buffers graphicsdisplays, or
`printers,
`because most display devices wo
`é
`rk from the upperleft an
`Seger zkEp reason, most devices use the coordinates aay, in ee
`cases Aaeeeieerunatss peaeys ponuye tebers, Seroae
`ew
`S where additional
`i
`i
`by the printer’s processor before actual daniomaie oF ne ane
`eet aaoe to the use of device coordinatesin displaying
`presented with a window a Aoge interface tool kits, the programmeris
`Presented to the programmer a fe BAACHOR for the display. This window 8
`Sa virtual display on which the programmeris
`
`Onesignificant
`
`ificati
`
` Re
`
`——
`
`

`

`
`
`Origin at upper left
`
`3.2
`
`COORDINATE sysTEMS *
`
`57
`
`
`
`—_. —_—$—$——
`
`y
`
`Figure 3-7 Device coordinates
`
`Origin at upperleft
`
`Figure 3-8 Windowcoordinates
`
`free to draw. Most such systemsalso provide a frame around this window that
`allows the user to manipulate the window’s location and size. The program’s
`coordinates are placed inside of the window as if the frame did notexist, as
`shownin Figure 3-8. The programmerthentreats the window asa display in
`and ofitself and generally ignoresthe larger space of device coordinates.
`Window coordinates and sizes, like display coordinates and sizes, are
`almost always expressed in pixels. Because some windowscan receive mouse
`events that are outside of their boundaries, mouse events in some systemsare
`reported in display coordinates rather than window coordinates. It is impor-
`tant to know howa particular system handles mouse coordinates so that the
`appropriate conversions are doneto makethe input coordinates and the draw-
`ing coordinates consistent.
`
`
`
`

`

`
`
`58
`»
`
`3°
`
`BASIC CompuTER GRA
`
`FP
`
`HICS
`
`hen dealing with display
`3.2.2 Physical Coordinates
`Pixel-based device coordinates can be a BOO ret is 20 pixels long on a
`devices of varying resolutions. For example, a line 4 ; laser printer. What we
`1024x1024 screenappears very differently on a ne its, such as inches, cen.
`need is to specify display coordinates in physical units,
`timeters, or printer points.
`laser printer in termsof inches,
`Let us suppose that we want to eek one
`00 dots (pixels) per inch laser
`Suppose also that we know that this isa é ,
`printer, The conversion from 5 inchestopixels i
`5 inches « 600 dpi = 3000 pixels
`Printer points for defining font sizes are defined oF 72 points to
`a 400-dpi printer, the height of 12-point text would be
`12points*Linch , 499 dpi - 67 pixels
`72 points
`Defining devices in physical units simplifies the formatting of displaysee
`be used on a variety of media butalso requires a multiplication of every co
`dinate by some constant. Because these conversions can cause a performance
`problem on low-end machines, sometool kits still present pixel coordinates
`as the modelfor devices and leave any conversions upto the application. Laser
`printers, on the other hand, have been forcedby their varying resolutions to
`present physical units as their coordinate model,
`
`ints
`
`to
`
`ae
`
`the inch.
`
`For
`
`3.2.3 Model Coordinates
`In manysituations, the information objects are modeled in coordinates that
`are very different from the display coordinates. In a word processoror drawing
`package, the coordinates of the model are in physical units for printing
`becausetheapplication is modeling exactly whatis going onto the page.
`For an architectural drawing, however, the model units are feet or meters
`when designing buildings. Thus a scaling transformation is required that
`transformsfeet, for example, into inches, which can then be used as physical
`display units. A possible scaling might be 10 feet to the inch. This would
`make the total transformation (for an example length of 22 feet) from model
`coordinates to a 100-pixel-per-inch display
`22 feet» Linch , 100pixels
`— 220 pixels
`10 feet
`linch
`j
`Theconstants in this formulaca
`ined
`n be combinedinto a simpler formula that
`can be usedon allpartsofthe drawingof the building:
`P
`
`

`

`52
`
`3.3
`
`HUMAN VISUAL PROpERTIES
`
`®
`
`If, howeve
`Sraheed, CAUSE
`n
`
`rT;
`
`..
`
`pelbpixe
`22 feet + —“BIXSI§ _ 720pixels
`oot
`h
`he scale of the drawing changes or the display device is
`t
`>
`Tar
`+
`>
`}
`Constants must be recalculated
`|
`
`3.2.4 Interactive Coordinates
`Up until now we
`received from Aeate ye considered SERUt Wet aes SeUbRooates
`directions whe toler oF other device, the mapping must workin the other
`Maree Ent AR £ general formula maps a point in some model coordi-
`a particular location on the screen:
`ModelPoint =
`'
`DrawScale « PhysicalToPixel + WindowOrigin = OutputPoint
`peatpeicesrenatomne this pointinto physical display units, Physical-
`:
`nes
`Ceeree S
`the
`point from physicaldisplay units into pixels, and the
`Bl
`ovesthe whole drawing to where the windowis located on
`the screen. WindowOriginis definedin pixels.
`If a mouse inputis received, it will be defined in pixels relative to the upper
`left of the screen, The transformation mustbe reversed to producea pointin
`model coordinates. This new transformationis
`
`The DrawSca
`
`;
`(InputPoint — WindowOrigin)
`_ ModelPoint
`PhysicalToPixel- DrawScale
`Weneed to have the input point converted to model coordinates so that we
`can use that point as information in changing our model of the application
`information.
`There are many moreissues involvedin defining the geometric mappings
`between application models and actualdisplays. The simple analysis we have
`done here is only the beginning. In Chapter 10, we will discuss a more com-
`plete system based on homogeneous coordinates and matrix algebra.
`
`3.3 HumanVisualProperties
`In order to interactively present informationto users, we need to understanda
`little about the human visual system. This understanding is essentialin
`that are understandable andpleasing
`nd interactions
`designing presentations a
`to the eye.
`
`
`
`

`

`
`
`60
`=
`
`3
`
`BASIC COMPUTER GRAPHICS
`
`3.3.1 Update Rates
`
`Early moviemakers were limited by their technology in ay numpetor cae
`of film that could be presented to a viewerin a second.
`Conseq
`y,
`y
`i
`yi
`ent but it does not look
`silent films appear very jerky. We perceive the movem
`yeehved totiewers
`real, Experimentation has shown that when images are presented
`tc i wers
`at more than 20-30 frames per second(fps), the images fuse together and
`appear to be moving continuously. This is because the frame rate has
`exceeded the rate at which the visual system samples the inputsto the retina.
`NTSCvideo is 29,997 fps, film is 24 fps, and PALvideois 25 fps.
`On a 30-MIPS(millions of instructions per second) computer—the avail-
`able rate when this book was begun—there are 1 million instructions avail-
`able to update the display frame in 1/30 of a second. Although : milion
`instructions seemslike a lot, rememberthat a 640x480display (television res-
`olution) has 307,200 pixels, leaving 3.25 instructionsperpixelif every pixelis
`to be manipulated between each frame. On a 300-MIPS computer—therate in
`commonuse by the time manyof you read this book—therearestill only 32.5
`instructionsper pixel per frame. This is a serious problem for video applica-
`tions.
`For normalinteractive use, however, we do not change every pixel in every
`frame; therefore the magic numberof 30 fps for smooth motionis not required
`for mostinteractive uses. If the user wantsto drag an object across the screen,
`experiments have shownthat 5 updates per secondto the object being dragged
`are sufficient to maintain the “interactive feel.” Obviously, improving this
`updaterate up to 30 updatesper second will make the movement appear more
`smooth and natural. For dragging tasks, 5 updates per secondis the lower
`bound for acceptable interaction. This meansthat ourdisplay update process
`for dragging purposes, must complete in less than 1/5th of a second to he
`acceptable.
`For interactions that are not continuous, such as displaying a new student
`record or finding a word in a document, delaysof 1-2. seconds are acceptable
`In ae situations, weare nottrying to create a smooth movement but are
`visually moving to a new context. Such context movements on the part of
`
`3.4 Graphics Hardware
`A brief introduction t0 basic graphics
`devices
`is
`;
`i
`devices for which ourimages willbe oe PEEtaa
`
`

`

`
`
`Frame buffer architecture
`
`Display
`controller
`
`Figure 3-9
`
`
`
`
`3.4.1 Frame Buffer Architecture
`The Rene buffer, shown in Figure 3-9, is the dominant architecture for dis-
`play devices. The graphics package, whichis part of the interactive tool kit
`running in the central Processing unit (CPU), sets pixel values into the frame
`buffer memory. The framebuffer is the repository of the image thatis being
`displayed on the screen.In manycases, the CPU can read the image outof the
`frame buffer as well as modify it. Various display technologies use differing
`techniques to convert the contentsof the framebuffer into a visible image.
`
`3.4.2 Cathode Ray Tube
`The most populardisplay device is the cathode ray tube (CRT), whichis the
`basis for standard televisions. For such a device, the display controller scans
`the frame buffer memoryfrom top to bottom,left to right to retrieve pixel val-
`ues. Simultaneously with this scan of the frame buffer, an electron beam is
`scanning acrosstheface of the display in a similar pattern. The display con-
`troller modifies the intensity of this beam based on thepixel values found in
`the frame buffer. This produces an image on the phosphorof the screen. In
`most color displays, there are three beams, onefor each of the primary colors,
`red, green, and blue.
`The phosphor image decaysbasedonthepersistence of the phosphor. Ifa
`long-persistence phosphoris used, the image will not decay by the time the
`display is refreshed again. Too long a persistence means that fast-moving
`objects have ghosts of the objecttrailing behind. Ifa low-persistence phosphor
`is used, then the image will start to decay before the display controller can
`redraw it, causing the display to appearto flicker.If the display is refreshed 30
`times per second, there is a conflict between ghosting from high-peinielsnes
`phosphorsandtheflicker of low-persistence phosphors. On good displays, t Hs
`is resolved by refreshing the screen 60 times per second (60 Hz) so that the
`user cannotperceivetheflicker. On higher-quality displays, this may go up to
`75 Hz.
`
`
`
`

`

`
`
`APH
`
`LoS
`
`z
`
`62
`.
`
`3.
`
`BASIC CompPuUTER GF
`5 Bennet This resolu-
`ber of suchdispl
`ays 1
`Padiution of American SEnats By aeineoe
`The resolution of a huge
`tion is determined by the reso”
`the developmér aisclavil Good-quality
`CRT I
`sas
`a tel
`evision,
`remrinehee, than just over computer atiot 1024x768, with
`Ae ll
`Chisforcompiter work have resolutions on the at oinig felch higher
`eine in the 1200%1000 range and experimentalsyst©
`
`amortize
`
`stal Display
`4.3 Liqui
`tal displays (LCD) because they are
`3
`Liquid Cry
`iquid c
`oe kBareelo
`Mostportable computers use liqui
`n the liquid crys-
`rys
`flat and have low power consumption. By placing
`stals is changed. When
`tals, the polarization of light passing through cae Bais eitennade Gane:
`used in conjunction with polarizing filters, such cry
`pareOPAuve isgeEh ‘que
`where the circuits for con-
`assive-matrix technique
`:
`ingenscepatllreeae
`hery of the screen and the settings
`trolling the crystals are located at the peripher
`h the screen. This
`of the various pixels must be done sequentially throug
`heel
`results in a constant image withoutflicker, but the time required to change
`pixel’s color is much slower than 30 fps. Depending on how slow this timeis,
`” or disappear while
`fast-moving objects, such as cursors, may “submarine”
`oO!
`moving quickly. This is because the cursor has moved from its location before
`the display wasfully changed.
`More expensive LCDsuse an active-matrix technology that places the con-
`trol circuitry for each pixel next to the crystals that are being controlled. This
`yields higher-contrast images, much faster times to change pixels, and elimi-
`nates the submarining behaviorof cursors.
`All LCDsuse a frame buffer architecture similar to that of the CRT. The
`difference is that the display controller is controlling the opacity of crystals
`rather than the intensity of an electron beam. Similar technology is used by
`display devices that have not yet gained a wide market, such as plasmapanels
`and others.
`
`3.4.4 Hardcopy Devices
`Bey coe are only indirectly involved with the user interface. How-
`anae ° the same software techniques—andin a good software Bens n
`code—are used to generate both hardcopy and screen output The
`SEMeseomenaesaero in the frame buffer of a hardcopy
`device.
`ldth
`is a large factorin drawing on a hardcopy
`plotter. This MeeTa for hardcopy graphical output is the pen
`One ofthe ol
`;
`asec’
`onthe stroke image model, except that the coor-
`
`d
`
`3
`
`

`

`odern |
`
`’
`
`«
`
`3.5
`ABSTRACT CANVas cLass
`=
`dinates of strok
`:
`:
`:
`h
`objects are sent to the plotter in physical coordinates. The
`lotter then
`all of the Tattybechiainatndl,Paper to draw the stroke, This process has
`Reed realistic images.
`:
`€ stroke model, including the inability to
`ficulty is sukingeanaare based on the frame buffer model. The primary dif-
`print a standard Ittapgiowware.f the frame buffer requires 3.6 megabytes to
`each pageis Prohibitive. Fy ae Communicating this much information for
`model. The most nopnlay;¢ bias reasons, laser printers generally use a region
`based on FORTH,2 whieh an nese is PostScript.! The PostScript language is
`driver software. The Believe#1 ye printer to be programmed by the print
`straight lines, and the Bdlacee ie cau are regions bounded by splines and
`initions. This methodallows rat
`s the frame buffer from these region def-
`and sophisticated images,
`very compact communication of very precise
`HtnearaonDnneey however, the region image modelis not suffi-
`Aavba Htc the Guinea os also accept pixel-based images that are then ren-
`,
`printer = frame buffer. Such images are usually much lowerin
`resolution than theprinter's resolution, which somewhat mitigates the com-
`munic