graphics.txt

书名:C语言科学与艺术,以前交钱下载的

                   A C-Based Graphics Library for CS1


                            Eric S. Roberts
                     Department of Computer Science
                          Stanford University


NOTE

This paper has been submitted to the Twenty-sixth SIGCSE Technical
Symposium on Computer Science Education.  Copyright is retained by the
author prior to publication release.

ABSTRACT

This paper describes a simple graphics library designed for a CS1 course
using ANSI C as its programming language.  The library can be
implemented easily on a variety of hardware platforms, providing a
reasonable level of portability.  Implementations currently exist for
compilers on the Apple Macintosh, the IBM PC, and Unix workstations; the
source code for each of these implementations is publicly available by
anonymous FTP from the Roberts.C.CS1 area on host aw.com.  In addition,
the public distribution includes a fully standard implementation that
generates a PostScript representation of the graphical image.

1.  INTRODUCTION

Getting college students excited about introductory programming is
harder in the 1990s than it was a decade ago.  Those who have grown up
with personal computers have strong preconceptions about what
constitutes an "interesting" application.  Modern technology has raised
the ante.  The simple text-based applications that are the mainstay of
most computer science textbooks offer little excitement to the student
who is used to modern graphical interfaces.  A program that sorts a list
of numbers -- as interesting as that problem may be from an algorithmic
perspective -- does not impress students who have played computer games
for years.

Using a graphics library in the introductory course makes an enormous
difference.  Even when the homework problems are harder than those
assigned in a more traditional course, students approach them with
considerably more enthusiasm, which in turn enables them to accomplish
more.  Captivated by the allure of computer graphics, beginning students
have been able to develop extraordinarily sophisticated programs.  I
have had students complete 1000-line programs in the fourth week of the
introductory course.

Beyond fostering excitement, using a graphics library has other
pedagogical advantages.  In my experience, requiring students to write
graphical applications early in the term turns out to be the most
effective way to drive home the concepts of parameter passing and
stepwise refinement.  In constructing graphical figures, students
immediately recognize the importance of parameters as they ask
themselves, for example, where to put a line or how big to make a
circle.  Moreover, creating the program structure necessary to display a
graphical image encourages students to master the technique of
decomposition.  Because the graphics library itself provides only a
small set of primitive operations such as drawing a straight line, the
student quickly learns to assemble lines into rectangles and other
composite figures.  As these figures are combined to form still larger
structures, the organization of the image suggests a natural
decomposition strategy for the program as a whole.

Although these advantages give computer science instructors a strong
incentive to integrate graphics into the introductory programming
course, doing so is complicated by the following factors:

   o  Existing graphics packages are usually designed for a specific
      implementation platform, which includes not only the
      underlying hardware but also the operating system, the
      compiler, and the runtime libraries.  An IBM PC program that
      uses, for example, a graphics package designed for Microsoft
      Windows will not run on the same machine under DOS, much less
      on a Macintosh or a Unix system.  Because of this high level
      of system dependence, the instructor who wants to use graphics
      must choose a particular platform and limit students to the
      graphical facilities available in that environment.

   o  Because there is no single graphical standard that works for
      all machines, textbooks written to attract the widest possible
      audience usually avoid the issue by omitting any discussion of
      graphics.  The instructor is therefore forced to develop
      supplementary course materials that explain how to use the
      local graphics facilities.

   o  Most graphics libraries are designed for use by experts, not
      introductory students.  As a result, those libraries are often
      too complex for novice programmers to comprehend.

Three years ago, when we started to convert Stanford's introductory
course from Pascal to C, we had to face these problems directly.  The
THINK Pascal system we had been using included a simple graphics library
that was well designed for use by beginning students.  Unfortunately,
the THINK C compiler we chose for the redesigned course offered no
corresponding facility.  Because our experience had convinced us that
using graphics strengthens the introductory course, we decided to design
our own C-based graphics library and integrate it with the instructional
materials being developed for the course.

The remainder of this paper provides an overview of the graphics library
and the strategies used to implement it on a diverse set of programming
platforms.

2.  INTERFACE DESIGN CRITERIA

The first step in developing the graphics library was to define the
interface.  In addition to more traditional principles of good interface
design, we wanted to develop an interface that met the following
criteria:

  1.  It must be simple.  At Stanford, we introduce the graphics
      library early in the term when students are first learning
      about functions and procedures.  Since the students have
      relatively few programming tools at their disposal, the
      graphics interface must not depend on advanced concepts such
      as pointers, records, or even arrays.  Moreover, it should not
      export so many functions than the novice programmer cannot
      understand the interface as a whole.  Beginning programmers
      can easily be intimidated by a large interface, even if they
      are not required to use all of the functions it contains.

  2.  It must correspond to student intuition.  The conceptual model
      that underlies the graphics interface must not be so
      mathematical or so technical that students have trouble
      understanding its operation.  They have usually been exposed
      to Cartesian coordinate systems in high school mathematics and
      are now beginning to become familiar with the procedural
      programming paradigm.  The design of the graphics interface
      should take advantage of that preexisting knowledge, even if
      the resulting conceptual model is at variance with the
      underlying model supported by the hardware.

  3.  It must be powerful enough for students to write programs they
      think are fun.  The principal advantage of the graphics
      library is that it allows students to undertake programming
      problems that are exciting enough to capture their
      imagination.  For this to be possible, the interface to that
      library must export functions powerful enough to generate
      interesting graphical displays.

  4.  It must be widely implementable.  To ensure that our approach
      would be relevant to a variety of institutions and not just to
      Stanford, we believed that it was important to implement the
      graphics package on several different platforms, particularly
      those used most often for introductory-level education.  We
      therefore designed the interface so that it did not depend on
      any specific platform.

In many cases, the individual criteria support one another in that
design decisions adopted to satisfy one end up advancing the others.
For example, choosing to leave a feature out of the interface results in
a library that is not only simpler but more portable, because there are
fewer features to implement for each new architecture.  In other cases,
however, the design criteria trade off against each other, which
requires the designer to balance the competing criteria and find an
appropriate compromise.

2.  EVOLUTION OF THE INTERFACE DESIGN

Fortunately, we have had the opportunity at Stanford to adopt an
evolutionary approach to the graphics library design.  In each of the
four quarters during the year, the Computer Science Department teaches
two versions of the introductory programming course: CS106A, for
students with little or no prior programming experience, and CS106X,
which combines the material in the standard CS1/CS2 curriculum into an
intensive one-quarter course for students with more extensive
programming backgrounds.  Both courses teach ANSI C using a library-
based approach [Roberts93] and use the graphics library extensively
throughout the course.  Thus, we can experiment with a particular
library design one quarter and refine it for the next.

We introduced the first version of the graphics library in the fall of
1992, the first quarter in which ANSI C was used for the entire CS106A
population.  At the time, the graphics library was very simple and
included only the following operations:

   o  Initialize the library.
   o  Move the pen to a specified position on the screen.
   o  Draw a line segment with displacements dx and dy.
   o  Draw a circle with a given center and radius.

Students were assigned several simple programs using the library and
could also to take part in an optional graphics contest.  The course
staff evaluated each entry on the basis of both its artistic merit and
its geometrical sophistication.  In addition, I invited the students to
suggest new features that would have helped them design an even better
entry.  The following are the most commonly cited suggestions, ranked
according to how many times each was cited:

  1.  Arcs (as opposed to complete circles)
  2.  Shaded regions
  3.  Simple animation (by erasing and redrawing a figure)
  4.  Color
  5.  Text
  6.  Mouse input

Having tried to design some graphical displays using the initial version
of the library, I was quite sympathetic to the students' concerns.
Adding the features they requested would certainly make the interface
more powerful and thereby make it more exciting for the better students.
Unfortunately, adding those features would also complicate the
interface, making it harder for other students to understand.  Perhaps
more importantly, adding features would make it more difficult to
develop implementations for a variety of platforms and therefore
compromise the portability criterion.

My solution to this dilemma was to separate the graphics library into
two interfaces: a simple graphics.h interface providing a minimal set of
fundamental tools and a more elaborate extgraph.h interface offering the
extended capabilities.  The textbook developed along with the course
[Roberts95] discusses only the simple graphics.h interface.  Students
who seek greater challenges, however, can use the features offered by
extgraph.h.  This design also promotes portability because an
implementation that covers only the functions in graphics.h is
sufficient for all the examples and exercises included in the text.  At
Stanford, the standard introductory course requires only the graphics.h
interface, while the accelerated course typically requires the use of
extgraph.h as well.

The contents of the current versions of each interface are summarized in
Figures 1 and 2 at the end of this paper.

4.  IMPLEMENTATION STRATEGIES

For the most part, implementing the rendering operations required by the
graphics library is not especially difficult.  Existing graphics
libraries invariably include facilities for drawing lines, displaying
text, and filling polygonal regions, which are the only primitives the
library requires.  Thus, to implement the procedures that actually
produce graphical output, all that is needed for each implementation is
a small amount of code to translate calls to the graphics.h interface
into the rendering calls required for the system graphics library.