Content uploaded by Michael Johnson
Author content
All content in this area was uploaded by Michael Johnson on Jul 06, 2016
Content may be subject to copyright.
INFORMATION TO U S ER S
This manuscript has been reproduced from th e microfilm m aster. UMI films the
text directly from th e original or copy submitted. Thus, some thesis and
dissertation copies are in typewriter face, while othe rs may b e from any type of
computer printer.
The qu ality o f th is r e p r o d uction is depe n den t u p o n th e quality o f th e co p y
submitted. Broken or indistinct print colored or poor quality illustrations and
photographs, print btoedthrough, substandard margins, and improper alignment
can adversely affect reproduction.
In the unlikely eve nt th at the auth o r did not sen d UMI a complete manuscript and
th e re are missing p ages, thes e win be noted. Also, if unauthorized copyright
material had to b e removed, a note will indicate the deletion.
Oversize materials (e.g., maps, drawings, charts) are rep rodu ced by sectioning
th e original, beginning at th e upper left-hand co m er a nd continuing from left to
right in equal se ctions with small overlaps.
Photographs included in th e original manuscript have been reproduced
xerographically in this copy. Higher quality 6" x 9" black and white photographic
prints a re available for any photographs or illustrations appe aring in this copy for
an additional charge. Contact UMI directly to order.
Bell & Howell Information and Learning
300 North Zeeb Road, Ann Arbor, Ml 48106-1346 USA
UMI*
800-521-0600
pe rm is sion o f the copyright ow ne r. Further reproduction prohibited without per miss ion.
Reproduced with perm ission of the copyrigh t owner. Further reproduction prohibited withou t permission.
Integrating HotViews and OpenG L
by
Michael C. Johnson
Thesis submitted to the G radu ate Faculty of
Christopher Newport University in partial
fulfillment of the requirements
for the degree of
Master of Science in
Applied Physics
20 00
Approved :
David Heddle, C ha irm an
David Doughty
John Hardie
Robert Hodson
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
UMI Number 1398494
UMI*
UMI Microform1398494
Copyright 2000 by Bell & Howell Information and Learning Company.
All rights reserved. This microform edition is protected against
unauthorized copying under Title 17, United States Code.
Bell & Howell Information and Learning Company
300 North Zeeb Road
P.O. Box 1346
Ann Arbor, Ml 48106-1346
Rep ro duc ed with perm issio n of th e copyright owner. Further reproductio n prohibited withou t permission .
A B S TR A C T
In te gratin g Hot Views a n d OpenGL
Michael C. Joh nson
M aste rs Degree in A p plied Physics. 2000
Dr. David Heddle, Asso ciate Professor o f Applied Phy sics
Scientific an d e ngine ering app lica tion s ha ve a un iq ue s et o f requ irem e nts. They must be a ble
to draw- complex ma chinery an d allow the u ser to in te rac t w it h it, pre se nt complex da ta in an
intuitive manne r, an d pr ovide for con trols an d use r in put. S oftware libraries a re helpful in the
creation of such a ppl ic ation s be ca us e the y provide co de for acco m plishing common tasks , s uc h as
grap hing d ata o r hand li ng user in p ut. T hey remove a level o f com p lication from the ap plication
code and allow the p rog ram mer to con c entra te on the tech n ic al c ore o f th e project.
Hot Views is a C lib rary for creatin g co ntro ls a n d d a t a v isu aliza tion progra ms. It provides th e
prog ra m m er with real-wo rld co ord in ate tracking, many kin ds o f interface widgets, help windows,
gr ap hs, and much m ore. HotView s h as b een used to c rea te a de tec tor display for th e CLAS
de tec to r a t Je fferson L ab. It has also been use d in com mercia l a ppl ic ation s.
OpenGL is a 3D gra phi cs lib ra ry specification, w ith ma ny implem entations on severa l plat
forms. OpenGL p ro vide s a n interfa ce to ba sic 3D graphics tools, suc h as frame and aux iliary
buffers, shading and li ght sources, an d t ext ure s. O penGL provide s for the use of o ptimize d 3D
display h ardw are. A p plication s ca n benefit from using 3D grap h ics because th ey ca n m ore a cc u
ra tely sim ulate the rea l w orld .
Th is p a per d etails th e creatio n of a new versio n of Ho tV iew s w hich allows software w ri te rs to
include 3D graphics in their GUIs, using O pen G L as a re n dering en gine.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
D e di ca ti on
To my wife, Angela :
Believe in yo urself
as you have believed in me
and you can do any th ing
And to my da u ghter , Ellissa :
I t ’s never to o early to s tart writing y o u r thesis
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per mission
A c kn o w l ed g em e n ts
Many than k s a re du e to Dr. Dav id Heddle for p atiently working with a stud ent who jugg le s
work, school, an d a family. M y apprec iatio n also go es o u t to J efferson Lab and to my boss. D ieter
Co rd s, fo r su p por ting me in m y pu rsu it o f the M asters D egree.
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
IV
Table o f C on tents
Dedication
................................................................................................................................................
ii
A c kn o w le d ge m e n ts
....................................................................................
ill
Table of Co ntents
...................................................................................................................................
iv
List of T a b l e s
............................................................................................................................................
vi
List of F ig u re s
................................................................................................................................................
vii
1. In trod uction
......................................................................................................................................
1
2. Motivatio ns for Hv3D
.....................................................................................................................
2
2.1. App lication Interfac e D eve lo p m e n t
.....................................................................................
3
2.1.1. Inte rfac e Bui ld ing T o o l s
.............................................................................................
4
2.1.2. Inte rface Building Libraries
.....................................................................................
5
2.2. 3D G ra p h ic s
...............................................................................................................................
7
2.2.1. 3D G ra p hic s L ib ra rie s
.................................................................................................
9
2.2.2. O p en G L
................................................................................................................................
12
2.3. H o tV i e w s
.........................................................................................................................................
14
2.3.1. E xam ple HotViews A p p li c atio n s
..................................................................................
15
2.4. A dvantages o f In teg r ate d 2D/3 D G ra ph ics in H o tV ie w s
....................................................
17
3. A 2D/3 D G rap hics Fra m ew o rk for Scientific Envi ro nm ents ........................................................20
3.1. Solving R end ering Conflicts from M ultiple S o u r c e s
............................................................
20
3.2. P roo f of Princ iple
.......................................................................................................................
21
4. Im plementation M e th o d s
.....................................................................................................................
24
4.1. Test P l a t f o r m
................................................................................................................................
24
4.2. V i su a ls
............................................................................................................................................
24
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
V
4.3. Co lorm ap s
.....................................................................................................................................
26
4.4. Pixm ap R e n d e r i n g
........................................................................................................................
26
4.5. M o t i f
..................................................................................................................................................
29
4.6. Top W indo w Optimiz ation
.......................................................................................................
31
5. C onc lu s ion s
................................................................................................................................................
34
Appendix A : A nnotated HotView s Libra ry Co de S e l e c tio n s
............................................................
35
Appen dix B : A nnot ated 3D Applic atio n C o d e
......................................................................................
40
R e fe re n ce s
..........................................................................................................................................................
47
Repro du ced with perm issio n of the copyright owner. Further rep rod uction prohibited without per mission.
VI
List o f T ables
T a bl e 1 The G r aph ic s Pipeline
..........................................................................................................
8
T a b le 2 Visuals and C o lo rm a p s
...............................................................................................................
26
T a b le 3 Widget Supe rclass / Sub class E x a m p le s
...................................................................................
30
T a b le 4 Widget Pare n t / Child Ex a m p le s
..............................................................................................
30
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
vii
List of F igu r es
F i g ure 1 View of a d rift cha mbe r from a physics d e t e c t o r
...........................................................
3
F i g ure 2 h vplot, a d a t a p lotting app licatio n c re ate d using H v
....................................................
4
F i g u re 3 Sam ple G U I wi th button s and t e x t
................................................................................
5
F i g ure 4 Sam ple 3D scene with reflection effect achieved thro u g h alpha blending .... 11
F i g ure 5 A 3D ob ject crea ted w ith O penG L
.....................................................................................
13
F i g ure 6 View o f a d e tec tor w ith con trols and rainbow b a r s
...........................................................
15
F i g ure 7 C ED : Clas E vent D i sp la y
......................................................................................................
16
F ig u re 8 Tigris : T rigger Inter active G ra ph ics
.....................................................................................
16
F i g ure 9 C A P S
............................................................................................................................................
17
F i g ure 10 Ph oto of t h e H all B drift ch a m b e r s
.....................................................................................
19
F i g ure 11 2D Sche m atic of the Hall B drift cham bers
....................................................................
19
F i g ure 12 Hv3D a n im a ted example 1, p art 1
...................................................................................
22
F i g ure 13 Hv3D an i m a ted exam ple 1, p art 2
...................................................................................
22
F i g ure 14 Hv3D ani m a ted example 2, pa r t 1
..................................................................................
23
F i g ure 15 Hv3D an im a te d examp le 2, pa r t 2
..................................................................................
23
F i g ure 16 Occluding e xam p le 1
..............................................................................................................
29
F i g ure 17 O cclu ding e xam ple 2
..............................................................................................................
33
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
1
1. In t r o d u ctio n
This pa per de scrib es the creation o f a g rap h ics Library an d framew ork to a ssist program m e rs
in w riting scien tific con tr ols a n d data vi su a liza tion a pplications. The m ost efficient way to do th is
is to integr ate separ a te lib ra ries, each of which cont ain s som e fun ctio nality t h a t we n eed . HotViews
provide s tools for c reating a technical app l ic a ti on c omplete with m ultip le views o f a device, plots,
help messages, coo r din a te feedback, and c o ntrols all n e atly t ied togethe r in a single s y ste m window.
OpenG L is a 3D graphics libra ry w ith s u p p ort for m a ny visual effects and drivers for specialized
grap hics h ard w are. I nte g rat in g these two g rap h ics librarie s will f acilitate the c rea ti on of scientific
prog ram s which can dis play complex info rmat io n in a n intu itive m a nne r.
The cen tra l p rob le m in th is proce ss involves re ndering conflicts betwe en H otV iews, OpenG L,
X W in dows, an d M otif. X W indows prov ides a w in do w man ag er an d a u niversal inter fa ce to the
un derlying simple 2D g rap hics hardw are. I t con tro ls which app licatio ns can r ende r to wh a t areas
of the disp lay screen , and specifies how they do so. HotViews makes all of its 2D dr awing calls
to X, and makes som e calls to Motif for displaying menus an d dialogues. O p enG L is typic ally
used alo ne, with no o ther gr ap hics lib ra ries, for the disp lay of 3D scenes an d ob jec ts. Op en GL
ap plic atio ns ty p ic ally work in full screen mo de, wh ere the window m anag er is tem po r arily s h u t off,
an d rende r di re ctly to th e scre en or to a single w in dow exclusively. OpenGL wo rks w it h X th ro ugh
GLX, an X W in dow e xten sion. This extens ion allows O pe nG L to r end er into a single window or
pixm ap. O pen G L o p era ti ons, especially a n im a tio n , tend to ov erwrite an y oth er pixels with in the
same window. We reso lve the se conflicts and reta i n each lib ra ry ’s individu al fun ctio nality .
In or der to do this , we carefully initialize all lib raries to pick the sam e display res ources and
utilize the sa m e c olorm a ps. We take ad v anta ge of Ope nGL’s a bility to ren der to a window or
pixm ap to allow i t to c rea te 3D g raph ics s e p a r a te fro m the graphics pu t dow n by o t h e r draw ing
routines. We cho os e o u r windows and o ther settin g s care fully so t h a t eac h libra ry r ende rs to the
proper sc re en a re as, even w hen parts o f an ite m are occluded.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
2
2. M otiv atio n s fo r H v 3 D
Scientific an d en ginee ring ap plicatio ns prov ide a spec ial challenge to p ro gra m m er s. They
usually re quire th e d is pla y o f geom e trically co m plex s che m atics along w ith n um erical or graphed
data. I t is usua lly nec essary for the app lication to allo w a ce rta in a m o u nt of interactiv ity w ith
th e rende red scenes. In m a ny cases, the prog ram m er is one of th e end users o f t he application.
Figure 1 p rcr id e s an e xam ple of an in te rface to a scientific ap p li catio n .
Physics expe ri m ents pro vide several e xam ples . T h e exp e ri m e nta l ph ysics commun ity is con
tin ually com ing up w ith packages to aid in th e quick d eve lo pm en t o f tech nica l application s, for
exam ple EPICS a nd R OO T. I n scientific env ir onm ents, th e man power to develop software from
th e gro und up in a low level gra phica l env iron m en t such as X W indo ws is missing. T he time
to develop software is a ls o con strained by the exp e ri m ental sch ed ule. As d etector s and system s
are cons tructed an d te ste d , con tr ol software is often ne ede d early in the p rocess. D ata visual
ization s oftw are is u se d d u rin g e xperiments t o verify and te s t th e d e tect o r systems, even before
ex perim ental results are sou g ht.
3D graph ic s libr aries a nd A P Is provid e a more physically rea listic disp la y o f an y real object
or scene th a n cou ld be achieved u sing simp le 2D draw ing routin e s. Ani m ated 3D gra phic s go a
step fur th er, giving th e u ser the ability to in ter act w ith co m plex sc enes by zoom ing and changing
viewing perspec tives. R end ering 3D gra ph ic s requires an ap p lication to t ra ck coo rd in ates in a
th ree dimensional Cart esia n s ystem an d to m ap thos e coor d in a te s to pixels on a two d im en sional
display. In ord er to render a re alis tic and visually p le asin g scene, however, much more may be
required. M o dern 3D h a rdw are and lib ra ries prov ide for num erous v isua l effects, such as lig hting
and tex tu res.
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
3
F i g u r e 1 View o f a drift c ham ber from a physics detec to r
2.1. A p p l icatio n Interfa ce D ev e lop m en t
A prog ra m m e r ha s a wide variety of ap p lica tions , libraries, and languages availa ble to ease
the developm ent o f ap p licat io n interfaces. T h e pu rpo se and aud ience of th e ap plic ation ca n affect
the choice o f to ol, as ca n the system a nd ma npo wer ava ilable to code it. Once chosen, the tool
or libra ry sh ould enab le t h e program m e r to c once ntrate o n implem en ting th e core p urp ose of the
applica tion. For scientific and en gineering ap plica ti ons , this may b e t he co ding o f a com plex d ata
processing frame w ork, or the descriptio n of a co m plex detec tor .
It is im po r tan t , once d ata is obt ai ned fro m a sim ula tion o r ex periment, to display i t in a useful
manner. W e may need to utilize cha rts, h istograms, an d o t h er types of plo ttin g to ols to achieve
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
4
this, as sho wn in Figu re 2. For co m plex detec to rs and o ther sy stems, it is also im porta n t for th e
us er to be able t o view* and cha nge th e co nfiguration o f the system . This m ay be easier on th e us er
if the program provide s a p ic tu re o f th e physic al sys tem itself. The interfac e to a technical p rog ram
may have sch em a tics and o ther i ll ustra ti ons of th e equ ip m ent, as well a s graph ic al controls a n d
fields to cha nge th e ir configuration .
VPI
M oor eft ou s*
1-OGeV
coa(e)
F ig u r e 2 hvplot, a d a t a plo tting a pplic atio n cr eated usin g H v
2.1.1 . I n terfa c e Build i n g T ools
RA D tools allow one to q uick ly assem ble a user in terface, o ften using a d ra g-and -dr op i nte r
face, with custo m izab le contro l widg ets suc h as scrollb ars, d ials, bu t to ns , t ext fields, and so on.
Figu re 3 shows a sim ple G UI. Often th ere are a few fairly s ophist ic ate d bu t specializ ed co mplex
widgets available , such as graphs . B ut most often these widgets ar e no t engineered for a d ata
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
intensive a pplic atio n. F or exam ple, a g ra ph w id get in such an a pplication m ay beco m e bogged
down a ft er on ly a few h u n dre d d at a p oints have been a d ded. T hese pack ages m ay ad d flexibility
to th e app lication b y pr o ducing actual tex t s ource co de, which can be al te r ed b y th e p rog ram me r
directly, allow ing one to cr eate a specialized ap plica tio n . This code ten d s to be larg e, however,
and hard to m ainta in . D raw ing a complex obje ct, such as a physics detecto r, can b e a foreb oding
ta sk using such tools, as ev ery piece must be d raw n m anu ally. [1]
More specialized e nviro n m e nts exist for th e dev elopm ent of co ntro ls and d a t a acq uisition
application s. Labview, for exa m ple, provides a g rap hic al prog ra m ming enviro nm ent an d device
drivers. One can link vario us modules t oget her to c re a te autom ate d sys te m s in a s hort am ount
of tim e. The display for m onitorin g such a sys te m tends to be very sim plistic. A lthoug h this is
ap p rop riate for a cryoge nic t arget, for example, i t fails to re n d e r very complex scien tific eq uipm ent.
The g raph ic al lan gua ge prod u ced is very inflexible a n d make s heavy use of s ystem memory an d
resources. One ca n not expan d on the ap p licatio n p r odu ced b y calling ou tsi de libra ries. [2]
F igu r e 3 Samp le G UI w ith bu tt o n s and t ext
2 .1.2. I n terfa c e B u ild in g L ibra ries
Pr ogram m in g a t a lower level provides us with m ore flexibility but m ay r equ ire m ore tim e
for dev elopment. This can b e g rea tly m itigated by u sing a function lib rary. A gene ral purpose
langua ge, such as C, has severed adv antag es :
• Porta bility : O ur p rogra m may be por te d betw een d ifferent op eratin g syste m s if we carefully
choose o u r API a n d u tilit y libraries. Such libr aries m u st e xist on m ore th an one p la tfo rm for
this to work.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
• P erform ance : A n editor and compiler (or S DK) gives us the g reatest control o ver the resp onse
tim e and e xec u tion time of ou r prog ram. We c a n find and elim inate bo ttleneck s, c rea te custom
d a ta str u c ture s , an d stre amline code as nee ded.
• Flexibility : Phy si cs experim ents an d o ther com plex syste m s requ ire interfaces th a t are com
plete ly unique . VVe c an choose to make calls to low level graphics ro utin es, or hig her level
widgets wh ereve r a ppropria te .
But if we don’t w ish to be bogged down by details o utsid e the pu rpose o f the a p plica tion, we
need to pick a graphi cs libra ry t o assis t us. O u r ch os en libr ar ies should be able to build GUIs, or
graph ical use r inter fa ces, a n d draw a r b itr ary item s t h a t we describe.
ROOT is a C+-f- class library dev eloped a t C E R N for large scale d ata ana ly sis p ro grams.
These classes p ro vid e tools for sta tistic a l a na ly sis and other processes used in a scientific envi
ronment. The RO O T framewo rk also comes with so m e useful de velop ment tools, suc h as a C-t~F
interpreter a n d a n o bje c t orie nted datab a se. For G UI building, it provides a rb itrary w rap pers to
the M otif widge ts a n d gr aph in g functions. F or d ete c tor d escription, it has an in te rf ace to O pen GL
for 3D g ra phics and fun ctio ns co ntaining 2D d raw ing prim itives. [3]
Ja va is a n inte rpre ted o bject oriented lan gua ge crea ted an d standa rd ized by Su n Microsys
tem s, and support ed o n a nu m ber o f platform s. Java provides a nu mber of class libra ries co ntain
ing graphics a nd GUI to ols. Work is even ongo in g t o support a 3D g ra phics interface thro u gh
OpenGL. Ja v a w as origina lly developed for web app licatio n s, b u t has ex pande d to gen eral p urp ose
program ming. [4]
Th ese env iro nm ents prov ide us w ith many too ls for d a t a processing a n d c ommun icatio n, but
only su pply the basics for bu ild in g interfaces. In o r d er to cre ate a n interactiv e disp la y o f a system,
we would have to call bas ic 2D draw ing rou tine s an d w rite our event hand le rs from sc ratch. Only
basic intera ctiv e widg ets would be pro vided for us , such as bu tto ns and tex t in p u ts . M ultiple
windows w ould b e h a ndle d by the sy stem , n ot th e library , which may n ot be very efficient if th e
application uses m any windows. R O O T provides co piou s g rap hin g abilities, while Java does n ot.
While d eveloping for Unix a nd the X W indow S ystem , we m ay choose to u se t h e X (X lib), X
Rep ro du ced with perm issio n of the copyright owner. Further reproduction prohibited without perm issio n.
Toolkit (Xt), an d Mo tif (Xm) libra ries. X provides b asic drawing an d w indowin g fu nct io n s. Xt
provides th e ability t o create graphical widgets a n d callback functions to h and le u ser i nput ev ents.
Xm provides a gen erous set of widgets th a t th e p rog ram me r or user may custo m ize. On e could
build an app li ca tion mak in g calls to the Xlib l ib r ary for draw ing graphics, an d t o Xt an d M o tif
for building a GUT. This w ould give us a fine level o f contro l over the style and perfo rmanc e o f our
graphic s, b ut we would hav e to build o ur g rap hical obj ects from scratch. In a d d ition to d raw ing
th e ob jects, we w ould ne ed to co de th e progr am resp ons es fo r interacting w ith th ese obje c ts .
2.2 . 3D G r a p h ic s
In order to ren der 3D sh ap es in a p leasing an d u seful mann er, we mus t be able to define
prim itive shapes in a th ree dimensional c oordinate s ystem . These shapes m ay b e poly gons, poly
hedrons, or som e th ing m ore sophisticated. In or der t o easily create or anim ate co m p lica te d sh apes,
we mu st also be able to scale, tran sla te , a nd r o tate o u r o bjects once th ey are defin ed. W hen using
a low level g raph ic s library, we build solid shap es o u t of co nn ec ted polygons by de fining the ir
vertices. These s hap es m ay be gathe red togethe r into compo site ob jects for e asi er ha n d lin g in
our code. A high level library might allow us to bui ld sh ape s out of a menu o f so lid ob jec ts,
and might also p ro vide rou tines for han dlin g th e shape s and accep ting us er i nput. Th is ty p e of
solid modeling make s it ea sier to c re ate scenes quickly, bu t the basic c ompu ta tions th emse lv es are
almost always done o n polygons, so a low level lib rary like O pe nGL passes inform a tion in te rm s
of vertices of poly go ns used as the bound aries of solid objects. Regardless, it is i m po rta n t th a t
our library provide rou ti nes for performing th e m at rix a lg ebra required to man ipu late obje c ts as
described above , a n d to ma p th re e dim ensional c oord in a te s to a two dimensional scree n.
Some special effects must also be su ppor te d in or d er to crea te a realistic scene. In ad ditio n
to re nd ering ba sic sh apes in various colors, a goo d gr ap h ic s libr ary will add sha ding, light so urce
effects, fog, alpha blen ding, an tialiasing, a n d textu res. Sh adin g and light sources make su b tle
changes to the co lor o f an elem en t depending on its location from an d angle to t h e view er. Fog
an d alpha blending allow th e mixin g o f pixels on t h e screen, which allows o ne to dr a w tr a n spare n t
and blurry shapes. A ntia liasing is a m ethod used to corr ect the jag ge d edges which m ay ap p e a r
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
8
wh en converting an analog line (defined by rea l number coordinat es) into discrete pixels. T his
ca n be accom plished by se lectively blurr in g a djace nt pix els. T ext ure s a r e flat pictures t h a t ca n be
tran sposed onto the sid es o f various sha pes . Eac h of these a dds rea lism to a scene and can help to
make it visually plea sing. T his list is n o t ex haustive, bu t th ese are th e m o st commonly p rovided
and often used special effects.
The graphics pipeline, shown in T able 1, describes the steps involved in processin g 3D graphics
inform ation. T hese stage s are mostly ind epe nden t and each sta g e ma y exe cute in parallel. This
allows for t he cr eation of dedica ted hard w a re which takes a d vantage of this para llelism . W hile all
stag es may be exe cu ted th roug h softw a re on a general pu rpo se CPU , t h e tre n d is for more and
more stages to be p rocessed by s pecial p urp ose h ardw a re on spe cializ ed video cards. Such cards
are available on high en d w o rks ta tions su ch a s those m ad e by SG I, but th e tech nolo gy also has a
tend enc y to trick le dow n into lower cos t PC cards. [5]
Stag e O u tp u t Description
Pr e-Pipe line Vertices in 3D co ordinates App lication d efines ob jec ts
Modeling
Tran sformation s
Vertices in 3D coordina te s Obj ects tra n sfo rm ed fro m in depen dent
system s to wo rld coo rdina te s
Tr ivial
Rejectio n
Vertices in 3D coo rd ina te s Cer ta in shap e s, such a s back facing
polygons, are dro p ped a t this stag e.
Illum ination Vertices in 3D coo rdina te s
an d colors
Object colors a re c reated using
m aterial pro p e rties a n d light sources
Viewing
Tr an sformation
Vertices in 3D coo rd inates
and colors
Objects a r e trans form ed from world to
eye co ord ina te s
Clipp ing Vertices in 3D coo rdina te s
an d colors
Objects no t w ith in the defined viewing
frustum (box ) are d rop p ed
Pr ojection Vertices in 2D coordina te s
and co lors
Objects are t ran s for m e d from 3D to
2D coord in ate s
Rasteriz atio n Pixels Objects a r e in terp o late d in to pixels
Display Light Pixels a re s ent to a display device
T a bl e 1 The Graphics Pipelin e
The pipeline can be d esc ri bed s tart ing with the 3D object inf orm a tion, typically defined
in term s of vertices, p olygon s, an d colors, an d moving thro ugh s tag e s unt il this inform ation is
ch an ged into pixels for display. M ost o f thes e stages involve c han gin g coor d in a te syste ms throug h
m a tr ix m ultip lications called t ra n sfo rm a ti ons. T h e modeling tra n sfo r m tak es care of reorienting
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
objec ts from th eir own co o rd inat e system to the world coor din ate system. Some ob jects may be
immediately disca rd ed a t this point since th e y are o ut o f view. L igh ting calculation s are don e
to illum ina te o bjects. A view er coo rdinate a nd o rienta tio n is u se d to trans fo rm all o bjects into
th e coordinate sy stem of the viewer. M ore ob je cts m ay be clippe d at th is point. T h e objects
are then tra nsformed o nce again into the 2D co ord ina te s ystem of th e s creen itself. Finally, the
graph ical d a t a is conv erte d into discre te pixels and sent to t h e disp lay area or frame buffer. The
mos t curren t g raphics h a rd w are ca n perform oper ation s fo r all o f th e se stag es.
Besides having de d ica ted p ro cessors. 3D graph ic s ca rds m a y also h ave specia l buffers p rovidin g
sp ec ial effects such as thos e shown in Figure 4. The se opera tions ar e o ften referred to as pix el
op era tion s, in c o ntrast t o t h e v erte x op erations de scribed a bov e. Th ese ca n inclu de a dou ble buffer,
for rende ring to an invisib le buffe r which is flushed to the s creen w hen com p le te. This p reve nts th e
viewer from seeing p a rti all y completed p ic tu re s. A d e p th buffe r keeps tra ck of the Z coo rdina te o f
each pixel, a nd e nsu re s the correc t display of ove rlayed obj ects. Stencil and accumulator buffers
ca n be used to p ain t special effects on some area s o f th e screen while leaving o th e r area s alone. In
ad d itio n , 3D graph ics ca rds ma y have d ed ic ated m em ory for tex ture s. [6]
More work is being rem ove d from the cen tra l pro ce ssor all the tim e. Unless th e pr ogram m e r
knows ex actly wh at s y stem th e so ftware will tu n on, it is im possib le to know which stages sho uld be
ex ecuted by s oftware a nd w hich will run on ded ic ate d har dware. A 3D graph ic s A P I like O penGL
take s ca re of this for us. I t contai ns routines to emulate all s ta ges in softw ar e, but sp ec ial device
driv er s will move the r esp onsibility to 3D h a rd w a re if it is su pplied. [5]
2.2.1. 3 D Grap h ics Libra ries
For a n a pplic at io n to render 3D graphics well, it of te n relies on th e presence of specialized
video hardware . T h is cre ate s two problems : it requ ires specialized code to tak e ad van ta ge of
a graph ic s device’s sp ecial abilities, and ma in tai nin g po r ta b ili ty acro ss platform s a nd graphics
devices requires c ompletely d ifferent code o r devic e d rivers in each c ase.
We need a 3D g rap h ics lib rar y which is supp o r te d on a num ber of platfo rm s, a nd which
co ntain s device d rivers for m any 3D video c ards. In or der to tak e a dvan ta ge o f a card’s abilities,
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
10
how ever, we need to giv e u p as m uch o f th e coding for the 3D graph ics as possible to the Library.
In othe r words, we want to push g raphics d at a into the top of th e aforem entioned 3D graphics
pipeline an d let th e lib rary h andle all steps up to the display. T his m ak es o ur coding even simple r.
We simply d escrib e wha t we w ant in the terse term s of colors a nd p olyg on vertices, and le t the
library' ha ndle the res t. O ur pr ogram is left to con cen trate on scientific co ding. [5] [7]
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
F i g u r e 4 Sample 3D sc ene w it h reflectio n effect achieved th roug h alp h a b le n din g
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
12
2.2 .2. O p e n G L
Op enGL is a 3D g rap h ics library. T he O penGL s pecifica tion describ es an API to a fun ct io n
lib rary an d sta t e m ach ine, which to gether d es cribe a n inter fa ce to an u nde rlying 3D gr ap hics
arch itec tu re. The O p enGL A PI has been referred to as a n architecture , highlig htin g th e fa ct
th a t different implem ent atio n s of t h e API may resu lt in d ifferent levels of p erfo rman ce, cost, and
capabilities. It is a widely acce pte d standa rd and is u se d b y m any ap plication s. D o cum entatio n
is available de ta ilin g ev e ry p a rt of th e library'. [6]
Im p le m entations o f O pen G L a re av ailable on alm o st a ll Unix platfo rm s, as well a s Microsoft
Window s a n d oth e r sy ste m s. O p enG L achieves this level of interoperab ility by caref ully de fining
the API to be sys tem in depe n den t. An A P I typica lly describes a softw are inter fa ce to som e
underlying sy stem, such as a specific k ind of h ard w a re or o peratin g system . The in te rface is
typ ically d escribed by a gr oup of functions in a library. G lide, for exam ple, is a l ib r ary o f fun ctions
for inte rfacing w ith 3D grap h ics c ards created by 3Dfic Intera ctive , Inc. T h e POSDC 1003.1 A P I
gives a list o f C fu nctio ns for perfo rm ing many s tandard sy stem task s w ithin an o p e rat in g s ystem .
The O pe nGL standard also specifie s a lib ra ry of fu nctions and ca lling standa r ds, but do es so in
a platform and hard w are inde pend ent mann er. There is no stand a rd implemen tation to borrow
code from, and fun c tion inp u ts, ou tput s, and sta tes are carefully an d com p letely specified. The
op eratio nal im p lem entation s of th e functio ns are left unspecified. [8] [9]
OpenG L was introduce d by S G I Inc. in 1992. T h e sta n d a rd is m ainta in ed b y an inde
pendent co nsortium wi th m e m ber s from many com p anies in th e c omputer graphics i ndustr y. A
conformance tes t su ite is ava ilab le to e nsure t h a t implem entatio n s are tru l y com p atibl e w ith t he
stand ard .
Many of the altern a t ive 3D libraries are connected closely to one partic u la r pla tfo rm . P E X ,
a library' bas ed on th e PH IG S library, is an exten sion to the X Window Sy stem . C ode com piled
using th is libra ry n e cessa rily on ly runs in th e X W indow Syste m , typically a Unix s ystem. And
no t all releases o f X come with this libra ry. I f we wa n te d to deve lop for Micro soft Windo w s we
could use Dir ec tX / D irect3D. Bu t if we wa nt o u r cod e t o b e po rta ble across man y plat fo rm s an d
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
13
to supp o rt many kind s of graphics c ards, O penGL is pr actically the on ly ch oice. Fig ure 5 p rovides
a sample of O pen G L ’s re nde ring abilitie s.
F igu r e 5 A 3D objec t created w ith O pen GL
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
14
2.3 . H otV i e w s
Scientific ap plication s ofte n req uire d a t a visualizatio n to o ls , su ch as rainb ow c h a rt s a n d plots,
and GU I building widg ets, suc h as bu tto ns and sliders . H otV iews provides a large selec tion of
tools for these purpo ses. B uilt in graph ic al item s prov ided in clu de butto ns, selection b oxes, text ,
LE Ds, option box es, r ainbow scales, sliders, and wheels. HotViews, o r Hv, also s u p p ort s g rap hin g
an d visu aliza tio n thr ough c o ordin ate trac k in g a nd copious d ra w ing ro utines. [10] [11]
But Hv also provides a u nique look and feature set spe cifically useful to scientific a n d engi
neering applica tions. Som e fe atures include : [10] [11]
• Item s may have d rag an d dr op ab ilit y a n d may be moved an d resized thr ough sim ple cursor
actions.
• Basic 2D drawing too ls are available from th e librar y a n d ma y be made available to th e final
applicatio n itself.
• A scientific p lotting tool is provided w hich s uppo rts spline s m oothing and curve fittin g .
• Support for animatio ns and simulations is provid ed thro u gh t im ed callbacks.
• Balloon a nd menu ba sed help may be easily in te gra te d in to t h e final applicatio n.
• There are m any fon ts a n d colors to sele ct from.
• Function keys may b e m appe d to us er functio ns
• A v irtual desktop allow s a n ap p lica ti on to take up a much lar ger working area t h a n is prov ided
on th e display devic e.
Hv provides a m a nag ing window w it h som e features of a M a cintosh desktop, suc h as a single
menubar. This main win dow co ntain s Views, which ar e subwindow s which m ay be dra gged, re
sized, and hidden. Views provide fun ction ality for p o in ter tra ckin g (feedback), scro lling , zoom ing,
zoom-to-fill, co ntro l widgets, an d more. F ig ure 6 displays a sing le Hv View. W ith in t h e main
draw in g area, called a H o tR e ct, an app lication can prov ide th e u ser with th e abi lity to d rag a n d
dr op items, or to find a n ob jec t’s p ositio n in retd world, no t pixel, co ordinates. T hes e and oth e r
features help th e pr ogr amm er easily provide the user w ith the abili ty to in te rac t with comple x
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
15
ob jects and data se ts . [10] [11]
Hv does not m ake spec ia l provisions for 3D grap h ic ren d e rin g within Views or H otR e cts.
F ig u r e 6 View o f a de te ctor w i th contro ls a n d rainbo w ba rs
2 .3 .1 . E x a m pl e H o t V i e w s A p p l ic a tio n s
Hot Views was dev elope d for scientific and eng in ee ri ng a pplicatio n s which p ro d uce graphi cal
outp u t and allow th e use r to int era c t with it. T h is m ay be a chiev ed d irec tly by clicking o n rep re
se ntation s of real world objects, or indirectly thro u g h b u tto n s an d controls. Severed a p plica ti ons
which use Hv help to il lus tra te the use of its un iqu e f eat ure s. [11] [10]
•C E D was developed for Jefferson L ab for the display of the CLA S d ete cto r. C E D , pictu red in
Figu re 7, provides f or several different views of the v ariou s co m pon ents of this dete cto r. O n e
un ique feature of the a pplic ation is the a bility to d isp la y d e tecto r d a t a over th e d i agr am o f
th e detector itself, p ro vid in g the user with a visual rep r ese n tation o f th e da ta. T h is d at a
can come from raw o r processed d a ta files, or even live f ro m th e detec tor itse lf thr ough Hv’s
simula tion callbacks.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
F ig u r e 7 CED : C la s Even t D isplay
•T I G R I S was also d evelope d for the CLAS de te c to r , b u t fo r th e pu rp ose o f specifying trig g er
paramet ers for t h e d e tec t o r’s reado ut electronics . A us e r ca n a ctu ally click on differe nt de
te c tor com pon en ts, spe cify ing th eir significance to t h e cu rre nt exp eriment. T h e app licatio n
tu r ns these g rap hical rep res entatio ns of th e ex p erimen t into d a ta for t h e trigge r electr onics.
TIG R IS is p ic tu red in F igure 8.
F i g u re 8 Tigris : Trig ge r Int era c tiv e Gr aph ics
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
•C A P S , pictured in Figur e 9, is a com mercial ap p lica tion using t h e H v library. S PA RT A, Inc.
of Mclean VA ha s d ev elop ed a th eate r missile defense sim ulatio n by combin ing a F O RTR A N
engine with an Hv gra phical inte rface. O bjects su ch as rad a rs and interceptors are placed o n
maps an d can t hen b e d ragg ed an d r ota ted . Once the H v interfa ce h as estab lishe d a scen ario,
it sends th e inform a tion to the FO RTR AN sim u la tion and, up on comp letion of th e sim ulatio n,
grap hically displays the resu lts. The u se r can the n inte rac t w ith th e re sults thro ugh the Hv
feedback mechan ism .
F ig u re 9 CAPS
2.4 . Ad v a n t a g e s o f I n t egrated 2 D /3 D Gra p hic s in H o t V iew s
Once we enable HotView s t o d ra w 3D shapes with in a View, an d incorpo rate con trols a n d
feedback into a n applic atio n , we will have a useful display for com plex physics detecto rs a n d o ther
systems. Many a pplicatio ns requ ir e a com plex set o f choices to b e prese nted to the u ser at once . It
does not necessarily suffice to assume th at th e user knows of all possibilities and ca n dig t hro u gh
hierarchical windows o r men us to ge t to th e app ropr ia te optio n . A par ticula r example is th e co ntro l
room environm en t of a physics de te ctor, w here an o p e rato r m ig ht need to be presented with a
physical view of a device, sca les, gr ap hs, a n d numerical feedback. Any o ne of these item s going to
a certain s tate or o ut o f a p a rticu lar ran ge could give the use r a n indica ti on o f abno rm al behav io r
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
18
in th e syste m . T h e integra te d natu re of Hv allows the ap p lication to display large amou nts of
graphical information a t once.
To thi s we would a dd a thre e-d im ension a l picture of t h e s y ste m . A solid ob jec t based 3D
pictu re of th e system c an be recognized more quickly. CAD a p plicatio n s, for e xample, have to
dr aw item s in 3D. The a b ility to ro t a t e a n d scale 3D scenes gives us an o t h er unique feature. I f
we c hange the orient at io n and per spe c ti ve of t he viewer, we ca n gi ve th e u ser a feel of travellin g
th ro u g h a 3D env ironmen t. This ca n m a ke it easy for the user to f in d a p a rticula r com ponent o r
lo ca tion t h a t he is looking for. 3D gra phics simply give a m ore i n tu i tiv e r epre sen tatio n of an y retd
object. Fig ures 10 and 11 sho w t h e difference betw een a re al d etecto r sys te m an d a typical 2D
sc hem atic of th at syste m.
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
19
F igu re 10 Photo of th e Hail B dr if t c h am bers
F igu r e 11 2 0 Sc hem atic of t he Hall B dr if t chambe rs
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
2 0
3. A 2D /3 D G r a p h ics Fra m e w ork for Scien tific En vir o n m en ts
Complex scientific a n d eng ineering ap plications req u ir e specific graphics libraries. The y re
quire fu nctionality for bui lding GUIs, display ing com plex d a ta, a nd in te ractin g w ith complex
renditions of equ ip m ent or environments. Basic GU I a n d graphics libra ries are not ad e q u ate to
th e task (see 2.1.1 & 2.1.2). Hot Views is useful in th ese e nvir onm ents, prov iding a fram ework a nd
fea tures needed b y m any ap plication s in these e nviro nmen ts (see 2.3 & 2.3.1). B ut a 3D d is play of
th e desired com p one nts or en viro nmen t will a d d d epth a n d info rma tion th a t the use r can be nefit
from (see 2 .4). Using a new version o f Hot Views in teg r ate d with Ope nG L will give applic atio n s
po rtability, since eac h lib rary is available on m a ny platfor m s. And we will reta in m o st of the
benefits of usin g e it her lib rar y o n its own. (see 2.2, 2.2.1, 2.2.2, & 2.3).
3.1 . S o lv in g Rend e r ing C o n flict s from M u ltip le S o u r ces
If the specific p ro blems of 3D grap hics r en dering, widget beha vior, a nd 3D graph ics h a rd w a re
su ppo rt are being handled by our chosen gr ap hics lib raries, o u r problem beco mes ge ttin g these
independen t p rog ra m s to coo perati vely rend er to the sa m e graphic s device. The re a re th ree
se parate rende ring engines to be concerned w ith h ere :
• X W indow s : This includes o u r window ing s yste m a n d window manager. All requ ests t o re nde r
in a n X system a re do ne th ro u gh the X W indows protoco l, e ithe r th ro ugh Xlib or a libra ry ex
ten sion. X therefor e co ntrols what rendering is allowed, tak ing care that occlu ded o r iconized
windows do no t ov erw rite a ny o ther part of the scree n. Full screen rendering is not typically
allowed.
• OpenG L : T h e O penGL A P I intention ally leaves any integr ation w ith the t arg e t sys tem ’s win
dow ing sy stem u nspecified. T his keeps the AP I p latfo rm independent. An O p enG L imple
men tation then ha s to prov id e f or commu nica tion w ith t he un derlying window ing sy s te m in
ad dition to im p le m enting the A P I ’s basic ab ilities. F or X Windows, this is done thr o u gh an
extension to X : the G LX extension. In its mo st triv ial imp lementation, GLX m ay sim ply
convert all Op enG L ren der in g requ ests in to p ixels a n d then make draw ing requ ests to X lib.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
2 1
A better im plem entatio n , however, will actua lly e x te n d the X protocol to include Op e nG L Ts
own 3D structu res .
• Hot Views is o u r 2D re n der in g engine, a nd will make calls directly to X to ren d er c ontrols, views,
items, and so on. It also uses Mo tif for th e display o f dialogues an d menu s.
Many of Ope n G L ’s spe cial effects involve ope rations which require ch an ging th e br ig h tn ess o f
a parti cular color. T h is mean s t h a t t h e library m ust ha ve access to a color schem e which allow s
one to num erically a d just th e b rightne ss of a given co lo r t o a n a rbitra ry d eg ree, s uch as a n RGB
colormap. If the color sch em e relies on a lookup index , w here th e pixel value is a n a rbitr a ry
number, then m a th op e ratio n s on those pixels are not usefu l. W hen using an RGB or even a
grayscale co lorm ap, however, in cr easing o r de creasin g a c e rta in n umber changes its brightne ss. In
ano the r examp le, colors can be mixed by averaging th e values of two pixels. For 3D gra phi cs it is
very desirable to have a n RGB color scheme.
3.2 . P r o of o f P r in c ip l e
A sample applicat io n is n eeded to dem onstrate the ab ility to ren der 3D g rap hics from w ith in a
Ho t Views ap p lica tion . Since all O p enG L applic ations ta k e the sam e basic ste ps for initi aliz ation ,
an d since crea ti ng ob j ect s for display is done ind epe nden tly o f th e interface to th e windowing
system, it sho uld be sufficient to c rea te an Hv applic atio n w ith one or more views con taining
3D ob jects. T h ere a re sev eral well known simple 3D ob jects which d em ons tr ate severa l as pec ts
of OpenGL prog ram m ing . The se o b je cts are often inclu ded in demons tr atio n pro grams released
with im plem entation s o f the Open GL library. I f we can em bed som e of these applic ation s into
an Hv framework, we will have demons tr ated a m eth od f or in te g ratin g O penGL app licat io n s with
Hv. We chose to im p lem ent the objects shown in Fig ures 12, 13, 14, and 15. To do this, we did
no t cre ate controls a nd feed ba ck , althoug h we could easily a d d th e m to a serious app licat io n a n d
re ta in our 3D effects.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
F ig u r e 13 H v3D a n im at ed ex ampl e 1, p a rt 2
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per mission
F ig ure 15 Hv3D animated ex a m ple 2, p a r t 2
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per mission
24
4. Im ple m en tatio n M eth o d s
To achieve the se goa ls, we need to a lter the HotV ie ws lib rary and im plem ent a sam ple ap
plication. Both the app lic ation a nd the libra ry will call f unctio n s from th e Op en G L libr ary. Two
source trees were dev eloped simultaneously du ring this p r o ject. O n e contains modified Hv code,
with changes design ed to allow OpenG L to ren der w ithin t h e Hv window. Th e o ther c ontains a
sample Hv application, the bulk of which is O pen GL code t o rende r 3D shapes. Th es e c alls obe y
th e O penGL A P I and m a ke no assum ptions a b out u n derlyi ng graphics h ardwa re . T h e goal was to
implement the Open G L demo program s w ith only th e m inim u m overhe ad needed to e m bed th e m
into Hv. In fact, mo st of our applicatio n code is ded icated to creatin g the 3D o b je cts in O p enGL.
4.1 . T est Pla tfo r m
HotViews run s on a dozen o r mo re different Un ix o p e rating syste ms from different ven dors.
It requires the X W in dow System a nd th e M otif graph ic s lib ra ries, bo th o f which are pre sen t or
available on mo st system s. Since OpenG L is pla tform in d epen d ent, we c an in c orp ora te it in to
HotView s w ithou t loosing po rtability.
Th e main te st pla tfo rm consisted of a Linux PC w ith no specia l graphics hardw a re. XFree86
provid ed an X im ple m entat io n, along with a Red hat release o f M otif. Mesa p ro vide d a n O pen G L
API. Mesa is a GN U open source im pleme ntation of t he O pe n G L libra ry A PI. A ltho ugh i t is n o t
a licensed im plemen ta tion , it does pas s mo st of the co nfo rm anc e t ests. Commerc ial versio ns of
OpenGL are typically licensed by SGI.
Th e X device configur at io n was se t up in tw o d ifferent ways to tes t the ap p lica tion beha vior
un der changing co nditio n s. O ne config uration pr ov ided a 24 bit T ru eC olor visual only, while th e
other allowed a n 8 bit visual of any visua l type . This h e lped to te st our po rt ability to system s
with different kinds o f display hardw are. On e sub sidiary g o a l of the software was to dyna m ic ally
de te ct different typ es o f reso urces and use the m a p p ropriate ly to facilitate th e display of 3D an d
2D graphics simultan eo usly .
4.2 . V isu als
X provides th e us er w ith two lan ds of o b je cts for graphic s o u tput, called dra w ables. T h e
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
25
window is used w he n g rap hic s o u tput is directed to the screen, alth ough such o u t p u t m ay be
dro ppe d or ignored if a window is iconified, oc clud ed, o r o th erw ise n ot visible. T he pix m a p is used
when graphics o u tput will n o t im m ediate ly be display ed, p erh a ps because it is de stine d for a file
or for l ate r use.
A draw able ha s m an y a ttr ibute s de sc ribing its beh a vio r. T h e d e pth of a draw able is a sim ple
in te ger indica ting how m any bits a re allo cate d for ea ch individual pixel on t he screen. A d raw ab le ’s
visual determ in es how thos e bits are transl ate d in to a colo r. T h e nu m ber and type of v isuals
allowed de pend on th e gra phics hardw a re be ing used. A color m ap gives an ex act m apping betwe en
ea ch possible combinatio n of b its in a pixel and t h e resu ltin g color displayed. C olo rmap s an d
visuals are conc ep tually s i m ilar: a draw able’s visual d escribe s th e genera l s tr u ctu r e of its colorm a p.
Table 2 shows the six av aila ble visual ty pes provide d by X W indo ws.
A monochrome colorm ap provides o nly blac k a n d w hite or g rays ca le information. Usually,
th is typ e o f co lorm ap wou ld only be used if th e g rap h ic s h a rd w are available could n o t produ c e full
color.
An single ind ex ed RGB colorma p describes th e color of ea ch pixel as prop o rtio n al mix tu res
of re d, green, and blu e elements in a n ind irect m a n n er. Ea ch pixel value is con sidered to be an
inde x into a tab le of R G B values, which can be ins e rted into the tab le in any o rder. Gra phics
hardw a re with few bits ava ilable for e ac h pixel, for exa m p le 8bp p (bits pe r p ixel), often u se sin gle
indexed colorma ps b eca u se mo re b its ma y be used in th e ta b le entries (24 bits, for ex ample) to
de sc ribe a finer gr adient o f a particu lar color. For ex ampl e, one could tak e h a lf of the e ntrie s in a
ta b le fo r an 8 bpp ind ex a n d c rea te 128 sha des o f yellow. W h en ren dering a p a rticu lar scene, this
allows one to trade off a p a lette o f some colors w hich a r e n ’t us ed for m ore sh ade s o f o th e r colors
wh ich are used.
A decom pose d i ndex colormap simp ly div ides e a ch pixel by group s of bi ts into s e p a rate indices
for the color co m p one nts o f red , green, and blue, much like the table does for the single ind exed
colorm ap s. So, fo r a 24 bit pixel, 8 bits may b e used apiece for red , green, an d blue. T h e re sul ting
se t o f th ree ta b le s uses m u ch less m emo ry than a single mono lith ic table. O ne m a y co n sider th e
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
2 6
co lo rmap a trivial m a pping u sing zer o for th e lea st inte nse color, a n d th e high est possible unsigned
in te ger for th e m ost inten se c olor. But th e prog ression o f co lor in ten sities in the se tab les can be
line ar or nonlinear, an d may be set up by th e system or the application.
Visuals also d ete rmine w h eth er a colormap ta ble is read-o nly o r may b e a ltere d.
Visual Ty pe Colormap R ea d / Write Colormap R ead -On ly
Monochrom e Grays ca le S t at ic G ra y
Single Index RGB Pseud oCo lo r StaticC olor
Decomposed Ind ex R GB D irectCo io r TrueC olor
T k b le 2 Visua ls an d Colo rm aps
4 .3. Colorm aps
For 3D grap hics, we p refer to u se an RGB colormap. This c an be ach ieve d s traigh tforw ardly
us in g a dec om posed ind ex colorm a p, such as TrueColor, or by using a single ind ex colorm ap an d
carefu lly allocating all colors in th e color tab le to correspond to a d eco m pos ition of the b its in th e
index. Mesa, for e xample, will u tiliz e a single index colormap in this man n er. Since ou r target
hardw are m ay have multiple visua ls availa ble, we m ust carefully se t up o u r defau lts a t window
in itialization time.
Each window in X is allowed to hav e its own c olormap. Ap plic atio ns usu ally s h are colormaps
unless they need to num erically specify s everal uniq ue colors. Colorm aps m a y not ha ve thei r table s
co m pletely filled at cre atio n tim e . H v used to pick th e s tan d ard sha red colorm ap of t he system
and as sign new colors to it where a llowed. If it ran o u t of room, it wou ld cre ate a new colorm ap.
Now, H v picks an d nam es its c olor s by selectin g a n ea re st m atch from th o se alr ead y p resent in
th e RG B colorm ap. T h e X lib rar y does this work for us; the calls to assign n amed colo rs sim ply
pick th e closest value if the colorm a p has alrea dy been filled, o r it will a ttach new colo r values to
th e c olormap if th e co lo rm ap is no t full.
4 . 4 . P ixm ap R e n derin g
OpenG L incorporates the id e a of m ultiple p ro gram thre a ds rende rin g to th e sa m e screen at
on ce . In O penGL terms, e ac h th re a d is b o u nd to a con te xt which c ontain s inform ation a bout the
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
27
OpenG L state machine, enab le d op tions, and buffers. GLX allows a thre a d 's context to be bound
to a window or pixm a p. Ren der in g to the Hv window directly c re ate s conflicts w ith the X based
rend er ing that Hv al re ady uses. In grap hics te rm s, OpenGL and X wrrite t o t h e same fram ebuffer.
To comp lic ate thing s fu r th e r, O pen GL a nd X a re both asynchrono us protocols, a nd the
prog ra m m er is n ot guarante ed t h a t o bject s will be ren dered in the s ame o rd e r as the y were called
in the progra m. T his can be pa rtially alleviated by using routin es to flush eith er pipeline to
synchro nize the two protocols. B ut, since O pe nG L routine s may ove rw rite an entir e framebu ffer,
th e entire X window would hav e to be redrawn each time a n O p enG L View was upda te d. This
would not result in good perfo rmance , especially if the 3D scene was anim a te d .
The re are some ways to a ssure th a t Open GL only draws to a po r tion of a window, such as
using clipping pla ne s, ste ncil buffers, or a viewport. However, w hen O pe nGL changes a scene,
such as in an an im atio n , it begins by clearing the framebuffer. T his eras es the e ntire window.
One could also chang e Hv dr amatic ally by m aking each View o p era te in a s epa rate system
window, creating them as ch ildren of the primar y Hv window. T his wo uld hav e a negative im pa ct
on p erformance, bec ause H v app li cations typica lly use m an y View s. But if we selected on ly
OpenG L views to o p e ra te in se p a rate windows, we wrould run in to prob le m s w hen th e window was
partially occluded by a non -O pen G L view.
X req uires t h a t all d ra w ing o r re nde ring be done within w indows. The workspace background
is called the ro ot window. All icons and m enu b ars are windows, as ar e a pplication windows. In X
term s , a child window is a window w hich is disp layed on top of an o ther, larger window called the
parent. If a child wind ow is display ed a t a ll, or realized, in X term s , th en it covers a re ctang ular
are a of its p arent window. S ib ling windows are children of the sam e p are n t. Siblings may partially
occlu de one anothe r. X keeps track of which window is on top by defining a s tacking order for
sib ling windows an d chan ging t h e or d er as t he windows are m a nip ula te d . X application s usually
create a child of the roo t window . T hey m ay o ptionally create c hild re n fo r th e application window
to ren der but to ns or pop up menus. T he ru les of t h e windowing sy stem would not allow a child
win dow to be c lipped pa rtially by the pare nt Hv main window. W indow s m a y o nly be partially
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
28
occluded b y siblin g wind ows . B y the se rules, we cou ld n o t rend e r o u r Ope nGL to a child window
unless we were sure t h at no oth e r views w ere partially oc clud in g the Open G L view.
We chose to bin d o u r G LX c onte xt to a p ix m ap created a t initial iz ation time. O ur O pen GL
rendering c an b e done to th is pixmap w ithout fea ring t h at it will era se an y p a r t of the Hv wind ow.
Once we ha ve c o m p le te d d raw ing a scene, we ca n verify th at the final pixels have been re nde re d to
the pix m ap by flus hing a ll O p enG L com m an ds using g lF lu sh . T h e co m pleted pixm ap c an th e n
be copied to the H v w in dow us in g XCopyArea. Th is co m m a nd, like m ost X comm an ds, takes as an
argu m ent a d ra w ing conte x t. T h is context con ta ins ge neral d raw ing in fo rm a tion , includ ing a list
of arb i tra ry regions th at th e com m and is n ot allowed to draw to. W e m a ke su re that the regions
include o ther views a n d item s th a t sho uld n ot be covere d. Fig ure 16 demon stra te s successful
occluding.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
29
F i g u r e 16 O cclud in g ex amp le 1
4.5. M o t i f
T he use o f M otif presents a n ad d it io n al pro blem. M o tif creates w id ge ts, which a re windows
with th e i r own visuals, d epths, a n d c olorm aps. T h ese cha ra cteris tics a re dete rm in e d b y the val
ues of resou rc e variables t h at e ach widget con tains . W id get behavior a n d res ource v ariables are
specified in a n objec t oriented mann e r, w ith sub clas se s inheriting these characteristic s from su
pe rc lasses. T able 3 illu strates some of the superclas s - subclass relatio nsh ip s of widge ts . N ote
th a t this only dete rm ines which res our ce variab les a w idget can have, not wh a t va lues they hold .
W idg ets also have a h ie ra rc hica l relations hip du e to thei r im p le m entation as windows. Some o f
th es e re la tion ships , called pare n t - child relatio nsh ip s, are shown in Tab le 4. For e xam ple a she ll
widget, w hich interac ts w ith the wind ow ma nag er, may contain a form w idg et. A fo rm widget,
which places widgets in a ge omet ric lay out, may c o ntain several b u tto n s.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
30
Widg et D e sc ription Superclass
Core Superclass o f alm ost all widg ets None
Com posite S uperclass of widgets with children Core
Cons traint Con trols g eo m etry o f child re n Com posite
M an ager Provides visual effects, eg shado w & high lig hting C o nstrai nt
Draw ingArea B lan k canvas for intera ctiv e d raw in g M a na ge r
Bulletin Board Allows child ren t o be plac ed a t x ,y cood inates M ana ger
Form C o n stra ins ch ildre n by defin ing their attachmen ts B u llet in B o ard
Shell H and les interaction w ith th e window manager Core
T a b le 3 Widget Supercla ss / Subclass Examples
There is no problem w ith s eparate widg ets o r windows using different visu al resource s, even if
they use different resources from their pa ren t windows. However, Hv, like m o st M otif ap plic atio ns,
creates a to p level widget for the entire applic atio n. I t then creates a form on w hich to place the
menu ba r a n d main graph ic s area , and the n a drawing a rea for th e main graph ics . T his d rawing
area is wh ere our O penGL graph ics will be rende red, and th erefo re it has to hav e th e c orrec t visual
resources.
Widgets g et their resource values from variou s sources. T he user can set the m d irectly by
passing ar gum ent lists t o M o tif functions. Some resour ce values can be set this way only a t wid ge t
creatio n time, while o th e rs can be se t any tim e. Som e reso urce values are inhe ri te d from parent
widgets, an d still oth ers are se t to d efau lt values.
This c ombina ti on of so urces for resource values can be h azardous. If the visua l, de pth , a nd
colormap of a widget or w in do w are n ot compa tible with each o th er , a fatal X Ba d M a tc h error
will result. If a w idget does not have a specfic resou rc e va riable for these, th en they will be set
au to m a tica lly by the lib rary to ma tc h th eir paren ts . W h en only d e pth is a reso urce for a widg et,
we must be careful to set a legal dep th for the inh erited visual a nd colo rm ap.
Hv Name W idg et T ype V isual D e pth Colormap P a r en t
Hv.top leve l Shell Yes Yes Yes None
Hv_form Form No Yes No Hv_topleveI
Hv.canvas D raw in gArea Yes Yes Yes Hv_form
T a b le 4 W idget Pa rent / Child Examples
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
31
This can be a very difficult b u g to t ra ck down. X Window s prov id es a n asyn ch rono us interfa ce
to the g ra phic s device, and err o rs can be rep orted mu ch la ter th e n the y were actually caused.
Ev en exp licitly syn chron iz in g th e library' with special d eb ugg ing functions does not gua ran te e
that we will see e rror rep o r ts s h o rtly after we cause a n e rro r. To compo und the problem. M otif
is asynchronous as well. W idg e ts may not be instan tia ted when we exp ect, an d n ot even in th e
ord er we would e x pec t.
To by pass th is c ompl icatio n, we decided to explicitly specify all v isua l resources for all w id gets.
To do this, the Hv libra ry n ow wra ps all XmCreate calls into trivial function s which a tta ch a new
argu m ent list con ta ining th e visua l resources. An additiona l ben efit o f homogenizing the visual
resources in this m ann e r is th a t a ll Hv widgets and subwin do ws will use the sam e colormap, and
moving the m ouse fro m w id get to widg et will n ot ca use colors to c hange.
4 .6. Top W indow O pt im iza t ion
Rendering t o a p ixm a p do es h ave some disadvantages. T he G L X extensio n decodes OpenG L
commands com ing in ove r the X protoco l a nd sends t hem to the gra phics hardw a re . A 3D v ideo
ca rd can have its own o ptim ize d c ommand s et, and GLX has drive rs built in for m any different
ca rd s. GLX can th en take ad vantag e o f ea ch car d’s abilities to provide faster rendering, b ette r
grap hica l detail, and spe cial effects. Th is p erformance im prove men t can be so dra stic th at th e X
message pro toco l itself act ually becom es the bottleneck. G L X provide s ano ther optim iz ation for
th is case and can bypa ss the X pro to col all together, usin g its own optim ized message protoc ol.
This is known as d irect rend ering . B ut we only g et these benefits w hen we render directly to th e
graphic s card ’s own framebuffer. T h is on ly happens w hen we b in d o u r co ntext to a window, not
to a pixm ap.
We can not dr aw som e of th e Views in sep ara te child windows a n d others in the HotView
main window b ecause o f the oc clud in g rules of X W indows . W h en a c hild widow is disp layed on
to p o f th e HotView s wind ow , it would draw over e verything w ithin its rectan g ula r area. No 2D
draw in g done m a nua lly by Hv to the m ain window w ou ld be visible in this area.
In one case, how ever, this would not m atte r. When a n O pen G L View is the top V iew,
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
32
th ere will be noth in g occ luding it an d a child window wou ld not interfere. Since th e u ser will be
in te racting w ith th e top View, i t is de sira ble for 3D a nim atio n in t his View to be m ost efficient.
Our O pen G L r end e ring routin e s d etect the presence of a t op View and t reat it a s a spe cial
case. Th e pixels in th is case a re sent d irectly to a child win do w r ath er than to a pix m ap as in
all oth er cases. T h e child window is cre ated, switched fro m co ntext to c ontex t, and d ele te d as
needed. W hen th is op tim iza tion is enab le d, the p rog ram c a nnot use Hv 2D items o r dra w in g
routines in the sam e Ho tR ect as th e 3D graph ics. In th is case, it would be b e tte r to co ntin ue
using th e P ix m a p m etho d which allow s for occluded region s.
The pe rfor m anc e gaine d from this o p tim iz atio n com es from offloading some of the p ro cessing
from the m ain C P U to th e 3D graphics h ardwa re , from by pas sing the unsuited X pro to col w hen
th e p ro gram is ru n n in g on the s ame s tation as the d isplay s creen , and from utilizin g t he s pecialized
ASICs, disp lay memory, an d te x ture mem ory that the 3D g rap h ics h ardware s up plies. The benefit
of this optim iza ti on will var y g reatly ac ross different sys te m s w ith differen t display' h a rd w a re .
Figure 17 shows a to p view ren d ered in an X window occluding a lower view ren dered in a
pixm ap. Note t h a t t h e u se r sees no difference be tw ee n a view ren der ed to a windo w o r a p ix m a p,
except th at t he win do w re nde ring m a y be fa ster and use fewer C P U cycles.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
F i g ure 17 O cclu ding e xam p le 2
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per mission
34
5. C on c lu sions
We have found a solutio n to th e m ultip le rend ering problem . The various librarie s ren der
cooperatively to the sa m e X Window. The y do so in a n efficient manner, ad ding to p rog ram
performance when d raw ing com plex scenes.
Th e new vers ion of HotViews requires an implem e ntation of OpenG L. This must be supp lied
separately. T he 3D fe atu re s s upp orte d will d epend on which OpenGL im p le m entation is used.
Once Hv is linked to th e Ope nGL implemen tation, ail of t he available 3D features are sup p o rte d.
HotViews imposes no a dditiona l lim itation s on 3D ren dering.
Hv is a la rge library , utilizing over 70000 lines of code . Ope nGL implem e ntations are even
larger. M esa, for instan c e, uses over 200000 lines of cod e. Op enG L h as m any implemen ta tion s,
su pporte d sy stem s, a n d graph ic s hardw are device s u p p o rt . R e writin g eith er library w ould b e an
enormous effort. B y in te g ra tin g b oth libraries, we allow the program m er to take ad v antage of
bo th libraries’ fun ction ality a t once.
Future work in HotV ie ws could include enabling r eal world coo rdinate feedback for 3D views.
Pbuffers, which are be in g introd uced in new er releases o f OpenG L , cou ld be utilized ins te a d o f
or in add ition to pix m aps. They would allow the sa m e kind of off screen rendering to take p lace,
bu t could utilize 3D graph ic s hardw are to incre ase pe rf orm ance. The solution s t h at we found
here could be tied into th e H otViews lib rary di re ctly v ia new op tion s and fun ctio ns, to allow
applications e as ier a n d tr ansp a rent access to the m eth ods we’ve invented.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
A p p e n dix A : A nn o ta t e d H o tV ie w s L ibrar y Co d e S e lectio n s
Changes m ade di re ctly to th e H otV ie ws lib rar y a re describ ed h ere . No te that this is o nly a
partia l listing.
A glo ba l varia ble h a d to b e add ed t o H v.h to track X v isual selection, alon g w ith the variables
that alrea dy track de p th an d colorm a p inf orm ation . A drawing c o ntrol bit had to be a dde d to
views to ind icate when they a re going inactive . T h e cu stom d raw ing ro u ti ne is called once m ore
while th e View is going inactive so th a t it c an sw itch co ntexts from th e to p w indow to a pixmap.
It will also un m ap the w indow , which may late r be m app ed by a different view.
#define Bv_GOXMOXA 02000
/* Bit 10 -> View is going to be deactivated */
extern
X V is u a ll n fo * H v_ vi sin fo ;
Pro to type s for the Hv M o ti f wra p per functions ar e global b ecaus e M otif w idgets may be
created in any mod ule.
/ *
-----------------
Hv_motif. c
---------------------
*/
ex tern void BvJMotifXnit (void) ;
extern
Hv_Widget
SvXnCreeteBulletinBoerdDialog
(Hv_Widget,
char
*, Arg
*, int)
extern
Hv_Widget
HvXnCreateCaacadeButtonGadget
(Hv_Widget,
char
*, Arg
*, in t ) ;
extern
Hv_Widget
BvXUCreateDrawingArea
(H v_Widg et,
char *,
Arg
*
, int) ;
extern
Hv_Widget
HvXmCreateFileSelectionDialog
(H v_Widget,
char
*, Arg
*, in t ) ;
Hv_ M a tc hvisu al was deleted from th e mod ule H v_ c o lor .c. It w as u se d t o discover the visual
class of th e default visual of th e display. W e no longer c on cern ourselves with the de fault visual,
dep th, or colormap of th e display. Instea d , we use GLX to hun t for a m o re d esirable configuration.
In o rde r to allow fall thro u gh cod e t o select name d colors from the colorm ap , we go a hea d
and fill in the global variables for d e fau lt colorm ap, visua l, a nd d e p th. W e use the disp lay default
co lo rm a p o nly if GLX happ ene d to pick a visu al which m atched the displ ay de fault visual.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
36
i f (D ef a u ltV is u a l (dp y , s c r ) == d efv is ) {
S i f d a f DEBUG
p r i n t f ( " U s ing D efa u lt R oot Window Co lor m a p. \n . " ) ;
# e n d if
defc m ap = Def a u ltC olorm ap(d p y ,scr ) ;
} also {
# i fd « f DEBUG
p r i n t £ ("U sinw New Colo rm ap . \ n " ) ,-
te n d if
/*
Hopefully, th is wi ll allow us to allocate colors later in
code, so
that the fa ll-th ro ug h w ill work
Don't worry about the RootWindow parameter
,
i t is only us
ed by
X to determine
th e p r op e r sc r e e n .
I use the screen to fi
nd a
window. Is n' t tha t sick?
* /
de fc m ap= X C re ateCo lo rmap (d py, RootWindow (d py, H v_ vis in fo -> s c r
ee n) ,
H v _ v is in f o - > vis ua l, A llocN o n e );
}
H v _visC la ss = H v _v i s i n f o -> c l a s s ;
All calls to XmCreateWIDGET were replaced with calls to HvXmCreateWIDGET, as in this example
from Hv.dlogs. c. These wrappers are defined in the module Hv_motif. c. This allows us to set
default resources for all widgets without excessively interfering with legacy code. We use these
wrappers in several modules.
submenu = HvX m Create Pulldo wnM e nu (rc, "optionaubm a n u " , NULL, 0)
t
popup = HvXm CreateO ptionMenu (r c, " o p tio n _ m e n u ", a rg , n) ;
These arrays in Hv_ in it. c set the features we ask GLX to look for in an overloaded visual.
/*
To get a GLX overloaded visual, we
will t ry these in order of preference */
/* Should get rid of the X_VTSUAL_EXT la ter */
i n t dblB u f RGB [ ] = (GLX_X_VISUAL_TYPE_EXT, GLX_TRUE_COLOR_EXT,
GLX_RGBA,
GLX_DOUBLEBUFFER, GLX_DEPTH_SIZE, 8, None};
i n t s n g lB uf RGB [ ] = {GLX_X_VTSUAL_TYPE_EXT, GLX_TRUE_COLOR_EXT,
GLX_RGBA,
GLX_DEPTH_SIZE, 8, N one};
i n t d blB u f [] = {GLX_DOUBLEBUFFER, GLX_DEPTH_SIZE, 8, None} ;
i n t s n g lB uf [ ] = {GLX_DEPTH_SIZE, 8, None} ;
X V isu all n fo * v is in fo ;
i n t s cre e n;
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
37
Motif and X t ini tializ ation was sim pler in the o lder Hv, consisting of a single call to XtVaAp-
p l n i t ia l i z e . We mus t brea k down this call into several s te ps in o rde r to be tte r cu stom ize the
visual reso ur ces used b y the m ain pa re nt w idgets.
/*
MOTIF INITIALIZATION : t oolk it , appcontext, and display */
X t T o o l k it l n i t i a l i z e ( ) ;
Hv_app C ontex t = X tC re a t e A p p l ica tio nC o n t e x t( ) ;
if
(fb r ) X tA p p S e tF a llb ackR es ourc e s(H v_ a ppC onte xt, ( S tr i n g * )fb
r) ;
H v _ d isp lay = X tOpen D isp lay (H v_ap p C o nte xt, NULL,
(S t r in g )Hv_appName, NULL,
(XrmOp tio nD escList)NUL L, ( C ard ina l)
0,
#if XtSpecificationRala ase > 4
(int
* )& a rg c,
#elsa
(C ar d in al * ) & arg c,
#endi£
( S tr i n g *)a rg v );
s c r e en = D e f a u ltS c r e en (H v _ d is p l a y );
Next, we incrementally attempt to get a desirable visual setup through
GL X
from the
X
Server.
/*
GLX INITIALIZATION : visual */
p r i n tf
("Trying for a GLX Doubla RGB Visual.\n")
;
v is in f o = g lX C ho o s eV isua l (H v_displa y , s c r e en , dblBufR GB );
if
( i v is i n f o ) {
p r i n t f
("Trying for a GL X Singla RGB visual.\n")
;
v is in fo = glX Choose V isu al( H v_ d isp lay, s c r e en , sn glBufR G B);
}
if
( I v is in f o ) {
p r i n tf
("Trying for a GL X Doubla Xndaxad Visual.\n");
v is in f o = g lX C h o o s eV isu a l(H v_ d ispla y , s cr e en , d bl B u f ) ;
}
if
( iv is i n fo ) {
p r i n tf
("Trying for a GLX Singla Indaxad Visual.\n"),-
v is in fo = glX Choose V isu al( H y_ d isp lay, s c r e en , s n g l B uf ) ;
}
if
( iv i s i n fo ) {
f p r in tf ( s td e rr ,
"Couldn't f ind a GL capabla visual.\n“ );
e x it ( -1 );
}
H v_ v isin f o = v is in fo ;
p r i n tf
("Hvjvisinfo Visual ID
:
Xx\n"
, XV isu allD F ro m V isual (Hv_v
i s i n f o )) ;
The top level widget, the application shell, is created manually.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
38
/*
MOTIF INITIALIZATION : shell */
H v _ t o p le ve l = X tV aAppC rea teS h ell ( (S tring )H v_a ppN am e, NULL,
a p p l ic a t i o n S h e l l W i d g e t C l a s s ,
H v _d is pl ay ,
X t N visual , H v_ v isinfo -> v is u a
XtN dep th , H v_ v isin fo - > de pt h ,
NULL);
T h e initialization o f th e new M otif m odule, the cre ation of the applic a tio n form w id ge t, and
th e assign m en t o f a co lo rm ap to t he top level widget mu st be done in a caref ul o rder in ord er to
as su re t h a t subwidg ets inher it the righ t values.
/* s e t
the colormap a ttribu te for the Hv_toplevel widget.
This may be inherite d by children. */
X tV a S e tV a lues( H v_ tople v e l, XmNcolormap, H v_ co lorM ap , NULL);
H v_ M o tif I n it( ) ; /* Se t
up default arguments for
widgets */
H v _ In itC on t ro l s ( ) ; /*
de fault values fo r control va
In Hv_view s.c, the V iew draw in g rou tine n ee de d t o be modified to ca ll th e u se r draw ing
ro utine on e last tim e w ith th e dra w co ntrol b it, Hv_GOINGIA set. T his allows our cus to m drawing
ro u tine to delete the o ptim izing to p window, if ne ed ed .
H v_S e tB it (&(V ie w ->dra w co ntr o l) , Hv_GOINGIA);
p r i n t f
("On* more timel.Vn");
Hv_DrawViewHotRect (View) ;
H v _C le a rB it(&( V iew -> d raw contr o l) , Hv_ACTIVE);
H v _C le a rB it(&( V ie w -> d r a w co ntrol) , Hv_GOINGIA);
T he H v j n o t if .c mo dule was a dde d to th e Hv l ib rar y to provide w r appe rs to all widget
creatio n fu nctio n calls. We d o th is in order to a lte r the a rg u m e nt lists p assed to all widgets.
#unde£ XMD EBUG
#include "Hv.h"
#include <3ta/KenuShell.h>
#include <Xte/FileSB.h>
Arg d a r g vt l O ];
int
d a rg c ;
rs */
H v_C rea te F orm ();
H v _ I n it B a l lo o n s ( ) ;
/* Set up main form */
/* i n i tia lize baloon help */
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
39
The initialization of this module, called in Hv_init. c, sets up a global argument list containing
the chosen visual, depth, and colormap of the Hv application.
v o i d Hv_ M otif I n i t () {
/*
Set up d efault argument lis ts fo r Motif widgets. I f a l i s t
already ex ist s, we will have to add these items to i t. */
X tS etA rg ( d a r g v [da rgc] , Xm Nde p th ,H v_v isinfo -> dept h) ;
X tS etA rg ( d a rg v [d a r g c] , XmN colormap ,Hv_c olo rM ap) ;
XtSetArg ( d a r g v[ d ar g c ] , X mNvisu al, H v _ v i s i n fo -> v i s u al ) ,-
p r i n t f ("HV D efa u lt V isu a l ID : * x \n " , X V is ual lD F rom Visu al (Hv_v
i s in f o - > v is u a l )) ;
p r i n t f ("HV D ef au l t Depth : % d\n ", Hv _ v isin f o - > d ep th ) ,-
}
A typical wrapper to an XmCreateVIDGET call looks like this. The calling argument list is
merged with the standard list created above, and the underlying function is called from the Xm
library'.
Hv_Widget H v X mC reat eB ulletin Bo a rdD ialo g (H v_Widget p a r e nt, c ha r
* name,
Arg * argv , i n t a rg c) {
Arg * n e w ar g s ;
Hv_Widget r w id g e t;
ne wargs = X tM er geA rgLis ts (arg v, a rg c , d ar g v , 2 ) ;
rw idget = X m C r eate B ulle tin Bo ardD ialo g ( pa r e n t, name, n e w a rgs,
a rg c + 2 ) ;
X tF ree ( ( c h a r *) n e w a rgs) ;
r e tu r n (r w id ge t) ,-
}
More trivial wrappers are created for gadgets. Since they do not actually create windows,
visuals are not important.
Hv _w idget R vJO aCreate C ascad aB u tton G ad get (Hv_ Widget p a r e nt, c ha r
* name,
Arg * argv , i n t a rg c) {
Hv_Widget r w id g e t;
rw id ge t = Xm C re a te C ascad eBut to nGad get ( p ar en t, name, a rg v, a r g
c) ;
r e tu r n (rw id g e t) ;
}
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
40
A p p e n d ix B : A n n o ta ted 3D A pplication C o d e
Th is sample a p plica ti on illustrates t he a bility to ren d er O pen G L grap hics from within a
Hot Views app licatio n. I t utilizes OpenG L ’s ab ility to co n ta in m ore th a n one copy of th e 3D sta te
machine to maintain diffe rent 3D objects in sep ara te views.
The code frag m ents which follow do not co ntai n th e co m p le te pro gram.
The p rog ram b egins by including headers nee ded for Op enG L and Hv. Each libra ry sho uld
also b e linked to th e applic ation a t compile time.
*include <Hv.h>
#include <atdlib.h>
#include <stdio.h>
# include <math . h>
#include <GX>/ffl.h>
#include «31</glx.h>
The X W indow d a ta st ructu re is for the top window optim ization. We only need o ne glob al
window stru c tur e b eca use th e re will only be one opt im ized View a t a ny on e time . E ach 3D
View type will h a ve an in st anc e of the d raw dat a s tr u c tu r e ty p e . It co ntains infor mation the
drawing rou tine will need, such as a drawable to rend er to, G L X and X drawing c ontexts, visu al
information, and mo re .
Window sub win ;
i n t s ub w in o wne r=- 1 ;
struct
d raw d a ta {
int
r o u t in e ;
D isp lay * dpy;
X Vis u a l ln fo * v i;
Pixm ap pm;
Window w;
GC x g c;
XGCValues xgcv ;
GLXPixmap gpm;
GLXContext c x ;
} ;
Global variab les ar e used to keep t ra ck o f the state of t h e fo ur s e p ara te 3D views. In this
example, the bou n cing ball, the velocity a n d r ota tion of the ball is significant, as well as th e BALL
integer which is u sed a s a ha ndler for th e d ispla y list.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
41
/*
Bounce */
static
GLuint:
maJca_ball (void)
;
static void ballbouncs
(Hv_View view ) ;
GLu in t BALL;
G L f lo at Z rot = 0 .0 , Z s tep = 6 .0 ;
G L f lo at Xpos = 0 .0 , Ypos = 1.0 ;
G L flo a t Xv el = 0 . 2 , Y vel = 0 .0 ;
G L flo a t Xmin = - 4 .0 , Xmax = 4 .0 ;
G L f lo at Ymin = - 3 . 8 , Ymax = 4 . 0 ;
G L f lo at G = —0 .1 ;
int
moving = 0;
The main function in a n Hv a p plica tion is usually sim ple. Hv_Go calls th e lib rary’s non exiting
event han dler . M ost of o ur work is d one in P r iv a te l n i ti a l i z a t i o n .
int main (int
a r g c ,
char
* * a rg v) {
int
e r r o r ;
H v_ V aI n itia lize ( a rg c, a rg v,
Hv_USEWELCOMEVIEW, T r u e ,
NULL);
if
( (e rr o r = P r iv a te In it ia l i z a ti o n ( )) != 0) {
p r i n t f
("Error
s
%d\n"
, e r r o r ) ;
p r i n t f (”
Something wan t wrong in initialization. \n") ;
e x i t ( e r r o r );
}
Hv_Go( ) ;
}
A se parate view is c rea te d for each 3D ob ject. T h e initializa tion fun ction, Sh owg lS etup View,
will tak e ca re o f some Ope nG L initializatio n . In Hv, a n im atio n is set u p throug h c allbacks using
Xt. The animation function is se t here. On e drawback of this m e th o d for te stin g p urposes is t h a t
sy stem performance is not exp loited sin ce frames ar e drawn a t a specific frequency. In o rder to
figure out th e max im um fram e rate , we would need to draw frames continuously in a se p a rate
th rea d.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
42
/*
Create In iti a l Views */
Hv_VaCreateView (
& v ie w l,
Hv_TAG,
Hv_INITIA LIZ E,
Hv_CUSTOMXZE,
Hv_FEEDBACK,
Hv_HOTRECTWIDTH,
Hv_HOTRECTHEIGHT
Hv_TITLE,
Hv_DRAWCONTROL,
Hv_SIMPROC,
H v_S IMINTERVAL,
NULL
) ;
"A. sp inn ing triangle"
Hv_NOHOTRECTFILL,
tr ia n g l e s p in ,
50,
TRIANGLE,
Sho w glSetup V ie w ,
Show glC usto m ize ,
S how glF B Fill,
300.
300,
T he op timized window is created here . It will be ma ppe d and u n m ap p e d late r in th e code.
Con figu ra tion of this w indow is simple sin ce it is merely a child of the ap plicatio n window an d
does n ot intera ct w ith t he window mana g er.
//
Will use th is subwindow fo r optimized rendering when View i
s on top
sw a. colorm ap = Hv_c olorM ap ;
Sh ow glSetu pV iew is called once for e a ch of the 3D views. The d ra w d a t a str u c tu re is in itialized
using values chosen in th e H v lib rary in it ia lizatio n rou tin es a nd s aved in libr a ry global variables.
/ /
Set up drawing area
struct
dra w d a ta * dd = m all o c
(sizsof (struct
d raw d ata ) ) ;
dd ->d py = H v_ d isp lay;
dd->w = Hv_mainWindow;
/*
Kind of brain dead : se t up the appropriate drawing routine
by
incrementing a var ia ble. */
d r o u ti n e + + ;
d d - > ro ut in e = d ro utin e ;
p r i n tf
("currsnt mai nWind o w widgst
:
%x\n"
, XtWindowToWidget (dd
-> d py, d d-> w )) ;
d d -> v i = H v_v is i n fo ;
A sep a rate GLX contex t is cre ate d for ea ch 3D view. Each c onte x t has its own copy o f the
OpenG L state m achin e. Effects o r tran sfo r m s in on e c onte xt h av e n o effect on the o ther .
su bwin = X C rea te W ind o w (H v_disp la y, Hv_mainWindow, 0, 0, 3 00, 3
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
43
/*
create an OpenGL rendering context */
dd->cx = g lX C re a t e C on tex t (dd -> dp y, d d -> vi,
/*
no disp la y li s t sharing */
None,
/*
favor d ir ect */
GL_TRUE);
if
(d d -> c x == NULL) { p r i n tf
("Could not create a cont ext . \n")
e x i t (-1 ) ;}
A pixmap mus t b e c r eate d , firs t in X, the n in GLX . GLX add s inform ation and resources
to th e pixmap, suc h as a ux ili a r y buffers. GLX ca n then h a ndle t h e pixmap e xactly as it would
ha ndle rendering to a wind ow. This is referred to as o verload in g th e visu al.
if
(! (dd->pm = X C reatePixmap (dd- >dp y, R ootW indow(dd->dpy, d d->v
i - > s c r e e n ) ,
HRMAXWIDTH, HRMAXHEIGHT, d d -> vi- > d e
p th ) )) {
p r i n t f
("Couldn't create a pixaap in X.\n");
p r i n t f (
"<3Xi Error : % d \n"
, g l G etE r r o r () ) ;
e x i t ( - 1 ) ;
}
if
( ! (dd->gpm = glXCreateGLXPixm ap ( dd-> d py, d d -> v i, dd->p m )))
{
p r i n t f
("Couldn't create a pixaap in GLX.\n");
p r i n t f
("OL E r r o r
s
*d\ n"
, gl G e tE rr o r () ) ;
e x i t ( - 1 ) ;
}
glXMak eCu rren t ( d d-> d py, dd->gpm, d d ->cx ) ;
We need to set u p an X d ra w in g con text even t hou g h we a ren ’t m aking calls directly to ma ny
X drawing ro utin es . C o p yin g t h e pixmap to a window r equ ires this a s a p arameter.
/ /
Haven
'
t s et xgcv
dd -> xgc = XCreateGC ( dd->d py, dd->w , 0 , & (dd ->x g cv) ) ;
Com mands like g lE na b le and g lD e pth F unc turn on fe atu re s in the O pe nG L lib rary.
g lC learD e p t h an d g l C le a rC o l o r perform o peratio ns on t h e frame buffer and auxillliary buffers.
g l L o a d ld en t ity , g lu P er s p e c ti v e , a nd g lT ra n sla t e f all o p e rate on the m atrices use d for co
ordin ate transform s. I t is im p o rta n t to no te th a t the op e ratio n s will o nly affect the s ta t e o f th e
cu rre nt G LX con tex t, in this c ase the triang le view.
Rep ro duced with perm issio n of the copy right owner. Further reproduction prohibited without perm issio n.
44
switch
(dd - > r o ut in e ) {
case TRIANGLE :
/*
setup OpenGL state */
g l E na b le (GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
g lC le a r D ep th ( 1 .0 );
g l C le a r C o l o r( 0 .0 , 0 .0 , 0 .0 , 0 .0 );
g lL o a d l d en ti ty () ;
g lu P e r sp e c t i v e(4 0 .0 , 1 .0 , 1 0 .0 , 2 0 0 . 0 ) ;
g lT r a n sl a te f ( 0 .0 , 0 . 0 , -5 0.0 ) ; g lR o ta t e f (-5 8 . 0 , 0 .0 , 1 .0, 0.
0 ) ;
break;
We create a custom item to reserve drawing space for our OpenGL rendering. We simply
inherit a built in Hv item, Hv.WORLDRECTITEM, and customize the drawing routine by calling our
own function. We pass the drawdata structure to this function.
GlCa nv as = Hv_ V aCr ea te Item (View,
Hv_TYPE, Hv_WORLDRECTITEM
/
Hv_U S ERDRAW, draw3d ,
Hv_USERPTR,
(void
*)dd,
NULL);
The draw3d function is where the most interesting work is done, aside from the visual con
figuration done in the Hv library. The drawdata structure is set up for use.
void draw3d
(H v_ Item Item ,
Hv _R egion r e g io n ) {
int
t e s tc lip ;
int
t e s t re s u lt ;
GLint i ;
struct
d raw data * dd = m a llo c
(sisaof(struct
dra w d ata ) ) ,-
dd =
(struct
d raw data * ) (I t e m -> u s e r p tr ) ;
Our drawing routine checks to see if the View is on top of till others. If it is, and the View
does not already own the subwindow, the subwindow is mapped to the screen. OpenGL rendering
is then bound to that window, and the program is bound to the 3D object’s OpenGL state.
If the View is not on top, the OpenGL rendering is bound to a pixmap.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
45
if (
(H v _vi ew s. l a s t
== I
tem->view)
&&
I (Hv_ Che ck B it ( Ite m ->v iew - > d r a w co nt rol, Hv_GOINGIA) ) ) {
p r i n tf (
"B EGIN : %d is on top.\ n"
, d d-> ro utin e) ;
if
(sub w ino w ner != d d-> ro uti n e) {
su b w in o w n e r = d d -> r o u ti n e;
XMapWindow(dd->dpy, s u b w in );
}
XMoveWindow(dd->dpy, su bwin , I te m -> a re a-> le ft , I te m - > ar e a- >t
op) ;
glX M ak eC urr ent (dd ->dpy , subw in, d d - > cx );
glV ie w po rt ( 0,0 ,3 0 0 ,3 00 ) ;
} else {
if
(s ubw ino w ner == d d —> ro uti n e ) {
XUnmapWindow(dd->dpy, s u b w in );
s u b w i n o w n e r = -l ,-
}
p r i n tf
("BEGIN
:
kd is not on top. \ n"
, d d - > ro u tin e ) ;
glX M ak eC urr ent (dd ->dpy , dd->gpm, d d ->cx ) ,-
g lV ie w port ( 0 ,0 , I tem -> ar e a -> w id t h , I tem -> are a- > he ig h t ) ,-
}
/ /
Construct the GL 3D commands
/ / The disp la y lis t depends on the shape being drawn
switch
(d d -> ro uti n e) {
A different drawing routine is chosen depending on the View.
case SFECTEX :
g l C le a r ( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ;
glL ig htfv (GL_ L IG HT 0, GL_POSITION, L ig htP o s );
g lP u s h M a t ri x ( ) ;
g lR o ta t e f(9 0.0 , 1 .0 , 0 .0 , 0 .0 );
/*
Typical method: diffuse + specular + texture */
g l E n a b l e (GL_TEXTURE_2D);
glLightfv(G L _L IGHT0 , GL_DIFFUSE, W h i te);
/* enable diffuse
* /
glLightfv(G L _LIGHT0, GL_SPECULAR, W hite ) ; /*
enable specula
r */
#ifdef GL_VERS ION_l_2
g l L ig ht M o d e l i(GL_LIGHT_MODEL_COLOR_CONTROL, GL_SINGLE_COLOR)
#endif
g lC a llL is t ( S p h e re ) ;
g lP o pM a trix () ;
break;
At the end of our drawing routine, we must again distinguish between rendering to a window
or rendering to a pixmap. Some extra work must be done after hushing the OpenGL queue when
we are drawing to a pixmap. The pixmap must be copied over to the window. This operation
interprets Hv’s occluded region information so that overlapping Views are not overwritten.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
46
/*
SwapBu££ers + Flush will work in ei th e r sh or db mode */
i f ( H v_v ie w s. l a s t 1= Ite m ->vi ew) {
p r in t f
("END : 9sd is not on
to p.\n * ,d d -> ro utin e ) ;
/ /
Next
,
copy pixmap to main window
glX S w a p B uff ers(d d -> dpy,dd-> p m ) ;
g l F l u s h ( ) ;
X Set R egion (dd ->d p y, dd-> x g c, r e g i o n );
XCop yArea (d d->dp y, dd-> pm , dd->w, d d -> x g c ,
0, 0, I tem -> a r e a -> w id t h , Ite m -> ar e a- > he ig h t,
X te m -> a re a -> le f t, I te m - > are a - > to p ) ;
} else {
p r i n tf
("END
:
is o n t op. \n"
, d d - > r o u t in e ) ;
g lX S w ap B uf fers (dd ->d p y ,s u b win ) ;
g l F l u s h ( ) ;
Severed fun c tions a re left to anim ate the sha pe s thr o u gh ca llba ck s o r cre ate display lists.
Callbacks for a n im a tio n usu ally ju s t a d just som e co ord ina te p aram et er which the dr aw ing ro utine
passes on to O pen G L th roug h a sim ple r outine such as
g lR o t at e f
. A small pa r t of o ne d isplay
list is show h ere as a n example.
glShadeM odel(G L_FLA T );
glN orm al3 f (0 .0 , 0 .0 , 1 .0 ) ;
/*
draw £ront £ace */
glBegin(G L_QUAD _STRIP) ;
for
( i = 0; i <= t e e th ; i+ +) {
a n g le = i
2.0
g lV e rte x3 f (rO
g lV e rtex3 f (r 1
g lV e rt e x 3 f( rO
g lV er t e x 3 f (r l
, w i d th * 0 .5 );
}
g lE n d ( );
* M_PI / t e eth ;
c o s(a n g l e ), rO
c o s ( a ng l e ), r l
c o s(a n g l e ), rO
c o s( an g l e + 3 *
s i n (a n g le )
s i n (a n g le )
s in ( a n g le )
w id th
w id th
w id th
0.5)
0.5)
0.5)
da), r l * s in (a n g le + 3
da
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
47
R e fe re n ce s
[1] “Borlan d C ++ Bu ilder 5” . 2000, Inp rise Corporation
[2]“Labview D e m o n st ra tion Guide ” , N a tiona l I nstru m e nts C orp oration , March 1996
[3]Rene Bran, Fons R ade m ake rs , “RO OT — An O b je ct Oriented D ata Analysis Fr am ework” ,
CER N , NIK H EF, 1997
[4]Cay S. Horstm ann , Gary C orne ll, “Core Ja v a 2 Volum e 1”, 1999
[5]Ro n Fosner, “All A b o ard H a rd w are T a n d L” , G ame Developer, A pril 2000
[6]M ark J. Kilgard , “R ealizing Op enG L : Tw o Im p le m enta tion s o f One Arc hitectu re ” , Silicon
Graph ics Inc., 1997 AC M S IG G RA PH Eurograp hics Workshop
[7]M ark Segal, K u rt Akeley, “The D esign of th e O penGL Grap hics Interface ” , Silicon Graphics
Com puter Systems, 1994
[8] “Glide Program m ing G u id e” , 3D6c Interact iv e I nc, J u n e 1997
[9]Mark Segal, Ku rt Akeley, “The Ope nG L G r aph ic s Syste m : A Specification” , S ilicon G raphics
Inc, March 1998
[10]David P. Heddle, “Hv Pro g ram mi ng M anu al ” , C h ristoph er N ewp ort Un iversity a n d Jeffers on
Lab, May 31 1996
[11] D avid P. H eddle, “Hv : A Gra phica l User I nterface Library- for Scientific and Eng inee ring
Ap plications”
[12]Mark J. Kilgard, David B lythe, De ann a Hohn, “System S uppo rt for Op enG L D irect Ren der
ing” , Silicon Graph ic s Inc.
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
48
Repro du ced with perm issio n of the copyright owner. Further reproduction prohibited witho ut per miss ion.
