A C-Based Graphics Library for CS1                            Eric S. Roberts                     Department of Computer Science                          Stanford UniversityNOTEThis paper has been submitted to the Twenty-sixth SIGCSE TechnicalSymposium on Computer Science Education.  Copyright is retained by theauthor prior to publication release.ABSTRACTThis paper describes a simple graphics library designed for a CS1 courseusing ANSI C as its programming language.  The library can beimplemented easily on a variety of hardware platforms, providing areasonable level of portability.  Implementations currently exist forcompilers on the Apple Macintosh, the IBM PC, and Unix workstations; thesource code for each of these implementations is publicly available byanonymous FTP from the Roberts.C.CS1 area on host aw.com.  In addition,the public distribution includes a fully standard implementation thatgenerates a PostScript representation of the graphical image.1.  INTRODUCTIONGetting college students excited about introductory programming isharder in the 1990s than it was a decade ago.  Those who have grown upwith personal computers have strong preconceptions about whatconstitutes an "interesting" application.  Modern technology has raisedthe ante.  The simple text-based applications that are the mainstay ofmost computer science textbooks offer little excitement to the studentwho is used to modern graphical interfaces.  A program that sorts a listof numbers -- as interesting as that problem may be from an algorithmicperspective -- does not impress students who have played computer gamesfor years.Using a graphics library in the introductory course makes an enormousdifference.  Even when the homework problems are harder than thoseassigned in a more traditional course, students approach them withconsiderably more enthusiasm, which in turn enables them to accomplishmore.  Captivated by the allure of computer graphics, beginning studentshave been able to develop extraordinarily sophisticated programs.  Ihave had students complete 1000-line programs in the fourth week of theintroductory course.Beyond fostering excitement, using a graphics library has otherpedagogical advantages.  In my experience, requiring students to writegraphical applications early in the term turns out to be the mosteffective way to drive home the concepts of parameter passing andstepwise refinement.  In constructing graphical figures, studentsimmediately recognize the importance of parameters as they askthemselves, for example, where to put a line or how big to make acircle.  Moreover, creating the program structure necessary to display agraphical image encourages students to master the technique ofdecomposition.  Because the graphics library itself provides only asmall set of primitive operations such as drawing a straight line, thestudent quickly learns to assemble lines into rectangles and othercomposite figures.  As these figures are combined to form still largerstructures, the organization of the image suggests a naturaldecomposition strategy for the program as a whole.Although these advantages give computer science instructors a strongincentive to integrate graphics into the introductory programmingcourse, 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 introductorycourse from Pascal to C, we had to face these problems directly.  TheTHINK Pascal system we had been using included a simple graphics librarythat was well designed for use by beginning students.  Unfortunately,the THINK C compiler we chose for the redesigned course offered nocorresponding facility.  Because our experience had convinced us thatusing graphics strengthens the introductory course, we decided to designour own C-based graphics library and integrate it with the instructionalmaterials being developed for the course.The remainder of this paper provides an overview of the graphics libraryand the strategies used to implement it on a diverse set of programmingplatforms.2.  INTERFACE DESIGN CRITERIAThe first step in developing the graphics library was to define theinterface.  In addition to more traditional principles of good interfacedesign, we wanted to develop an interface that met the followingcriteria:  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 thatdesign decisions adopted to satisfy one end up advancing the others.For example, choosing to leave a feature out of the interface results ina library that is not only simpler but more portable, because there arefewer features to implement for each new architecture.  In other cases,however, the design criteria trade off against each other, whichrequires the designer to balance the competing criteria and find anappropriate compromise.2.  EVOLUTION OF THE INTERFACE DESIGNFortunately, we have had the opportunity at Stanford to adopt anevolutionary approach to the graphics library design.  In each of thefour quarters during the year, the Computer Science Department teachestwo versions of the introductory programming course: CS106A, forstudents with little or no prior programming experience, and CS106X,which combines the material in the standard CS1/CS2 curriculum into anintensive one-quarter course for students with more extensiveprogramming backgrounds.  Both courses teach ANSI C using a library-based approach [Roberts93] and use the graphics library extensivelythroughout the course.  Thus, we can experiment with a particularlibrary design one quarter and refine it for the next.We introduced the first version of the graphics library in the fall of1992, the first quarter in which ANSI C was used for the entire CS106Apopulation.  At the time, the graphics library was very simple andincluded 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 andcould also to take part in an optional graphics contest.  The coursestaff evaluated each entry on the basis of both its artistic merit andits geometrical sophistication.  In addition, I invited the students tosuggest new features that would have helped them design an even betterentry.  The following are the most commonly cited suggestions, rankedaccording 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 inputHaving tried to design some graphical displays using the initial versionof the library, I was quite sympathetic to the students' concerns.Adding the features they requested would certainly make the interfacemore powerful and thereby make it more exciting for the better students.Unfortunately, adding those features would also complicate theinterface, making it harder for other students to understand.  Perhapsmore importantly, adding features would make it more difficult todevelop implementations for a variety of platforms and thereforecompromise the portability criterion.My solution to this dilemma was to separate the graphics library intotwo interfaces: a simple graphics.h interface providing a minimal set offundamental tools and a more elaborate extgraph.h interface offering theextended capabilities.  The textbook developed along with the course[Roberts95] discusses only the simple graphics.h interface.  Studentswho seek greater challenges, however, can use the features offered byextgraph.h.  This design also promotes portability because animplementation that covers only the functions in graphics.h issufficient for all the examples and exercises included in the text.  AtStanford, the standard introductory course requires only the graphics.hinterface, while the accelerated course typically requires the use ofextgraph.h as well.The contents of the current versions of each interface are summarized inFigures 1 and 2 at the end of this paper.4.  IMPLEMENTATION STRATEGIESFor the most part, implementing the rendering operations required by thegraphics library is not especially difficult.  Existing graphicslibraries invariably include facilities for drawing lines, displayingtext, and filling polygonal regions, which are the only primitives thelibrary requires.  Thus, to implement the procedures that actuallyproduce graphical output, all that is needed for each implementation isa small amount of code to translate calls to the graphics.h interfaceinto the rendering calls required for the system graphics library.