Department of Statistics
The University of Auckland
gridpackage that are either impossible or unnecessarily difficult and/or inefficient with the current API.
[R base graphics] [graphics engine] [graphics devices]I want it to look more like ...
[R base graphics] [graphics engine] [graphics devices]which makes it much easier and nicer to do things like ...
[R base graphics] [grid graphics] [graphics engine] [graphics devices]This obviously implies changes to the graphics API (hopefully to make it cleaner), but also implies a new device API.
An important thing to define is what I think of as the graphics engine.
This basically consists of (most of) the calls in
that start with a
...). I want to be able to call these (rather than calling
devices directly) because they have (at least) lots of useful stuff to do with
clipping that I would not want to write all over again.
An important part of extricating the R base graphics code
from the graphics engine
and the devices will be a change to passing all
type things explicitly in the calls to the graphics engine (which then
passes them explicitly in the calls to the graphics device). At the
moment, we have horrible things like the device reaching back up to
the R base graphics to find out what the current
settings are. This has the nasty side-effect that, in
grid, in order to modify something like the colour
that the device uses to draw a rectangle, I have to set
. This is not possible in C code, so I have to do it in R code and
suffer a speed penalty.
Ideally, devices should know nothing about
In a bit more detail, this change would mean not passing an enormous
DevDesc structure to the device. In particular, no
R-base-graphics-specific information would be passed to the device. The
device just gets sent colour, linewidth, font specification, ... There
would still be a need for some device state (e.g., what is the "current"
device colour) --
threading-related issues here?
Ultimately, all devices would need to be modified. This will hopefully
mostly involve just fiddling the arguments to existing functions, plus
simple changes along the lines of
col. However, there may be a couple of more
involved changes, which may require input from the device driver
setClipRect). This code is very GRZ-oriented and I want to be able to set an arbitrary rectangular region.
Ideally I would like to be able to set an arbitrary rotated rectangular region, but I will probably leave that for now. Really ideally, I would like to be able to set an arbitrary clipping region, but that's definitely longer term.
GNewPlotis another hodge-podge of GRZ-oriented bits and graphics engine bits. Needs pulling apart -- some bits go into new graphics engine functions (e.g., some sort of
GNewPagefunction) and the rest becomes an R base graphics
DevDescstructure that indicates whether a device is a "new" device. All existing devices set it to
devLine, etc. and make it exported. A first hack at what this might look like is given here.
newDevX11.c) based on current device code, but conforming to new device driver API.
gridbased on current graphics engine code, but which make use of new device driver API. This converts
gridto new graphics engine and new device drivers (but means that
gridwill not work with existing device drivers).
graphics.cto use new device driver calls if device is a "new" device. (Do NOT replace these calls with new graphics engine functions in
gridyet -- that may have to wait until post-1.4 because it will require rewriting all of R base graphics to use the new graphics engine.) Test this on newX11 device.
grid(because the new graphics engine functions in
gridwill be mostly just copies of the
graphics.c). This could cause problems if, for example, a bug is fixed in
graphics.cand the corresponding fix is not made in
grid-- when the new graphics engine replaces the code in
graphics.cthe bug is lost.
grid, and R base graphics working just as it does at the moment. It would allow me to speed up and tidy up
gridand fill in some of the important missing bits. It would also mean that R base graphics would be ready for changes to use the new graphics engine and for a potential clean up. Once that has been done, the graphics API could be changed (basically to expose the new graphics engine) so that other "external" graphics code can make use of it (the new device driver API would not be advertised until this time).
plotmath.ccode needs to be part of the graphics engine. Any problems there?