... 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.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc., Washington, D.C.

Return to AIPS++ Home Page
2006-10-15