- ... client.1
- The glishtk
client is a Glish proxy client which provides the Tk widgets to
Glish.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... cells.2
- For some devices, the
concept of color cells is invalid, and the ColorTable simply makes
things ``look like'' some number of cells has been allocated.
Differences like these - between devices - are encapsulated by the
PixelCanvasColorTable class.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... possible3
- Note to developer: a particular
recommendation is that this interface be pruned to perhaps provide
just Int and Float interfaces.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ... class.4
- For the real details, examine the
implementation of CachingDisplayData::refreshEH while you read
the following notes:
- 1.
- First we just find out the WorldCanvas we're dealing with, and
likewise the WorldCanvasHolder. Next we get a copy of the
restrictions on the WorldCanvasHolder. For our DisplayData `NGDD'
to draw, it will have to match some of these restrictions.
- 2.
- To the WorldCanvasHolder restrictions, we add the state of the
WorldCanvas - basically we describe its geometry on the
underlying PixelCanvas. Then we get a copy of the restrictions
on the DisplayData, and to this copy, we add restrictions which
describe the options the user has set on the NGDD. This is done
with the line:
ddRestrictions->add(optionsAsAttributes());
- 3.
- If caching is on, we search our list of previously made
CachingDisplayMethods, to see if we can find one whose restrictions
match the two buffers created above, and if they have in the
past been drawn on the WorldCanvas we're supposed to draw on
now:
- If we don't find such an element ( if (!found)
{ ... }) we construct a new one by calling the method
newDisplayMethod, which must be implemented in
derived classes, and add the result to our list. We keep a
pointer to it though, since we'll draw it below. The
purgeCache call is made to make sure the cache doesn't get
too large.
- If we do find such an element, let's do nothing, because
cdMethod now points to it, so we can ask it to draw just a bit
lower down in the code.
- 4.
- On the other hand, if caching is off, let's just make a
new displaymethod using the newDisplayMethod function, but
we'll delete it after we use it!
- 5.
- So now we can delete the restriction buffers we used to
compare to our list of already drawn "views", we install a
Colormap if required, and just ask the method to draw itself:
cdMethod->draw(ev.reason(), *holder);
- 6.
- Finally, if caching is off, we just delete the cdMethod
pointer and free the memory used by our drawing.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.