[rrd-developers] Image clipping/stacking wanted in 1.1.x (Was: "Re: rrdtool 1.1.x rendereing")
Jakob Ilves
jakob.ilves at oracle.com
Mon Mar 5 12:06:36 MET 2001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello!
Of course this is a long mail, what else to expect from me ;-).
INTRO
I would like rrdtool 1.1.x to support that images generated consists of partial
graphs. A partial graph could be a graphic consisting solely of a timescale
X-axis. Another partial graph could be just the graphed curves and areas
themselves (with X- and Y-axis graphics, paddings, legends etc. clipped away ).
HOW RRDTOOL 1.0.X WORKS TODAY
To illustrate, here is what is included in a MRTG image today (a bit badly
scaled, I admit...)
+--------------------------------------------+
| (Upper padding) |
| Image Title r|
| i|
|L Y+--------------------------------+ g|
|e a| | h|
|f x| Graph with curves | t|
|t i| and areas. | |
| s+--------------------------------+ p|
|p X-axis a|
|a d|
|d Label for incoming traffic d|
|d Label for outgoing traffic i|
|i Text about current in & out traffic n|
|n Text about average in & out traffic g|
|g Text about maximum in & out traffic |
| |
| (Bottom padding) |
+--------------------------------------------+
If someone using rrdtool 1.0.x as of today and tries to get a "minimal" image,
the following is the result:
+--------------------------------------------+
| (Upper padding) |
|Left Y+----------------------------+ right|
|pad a| | pad|
| x| Graph with curves | |
| i| and areas. | |
| s+----------------------------+ |
| X-axis |
| (Bottom padding) |
+--------------------------------------------+
As we see here, 1.0.x rrdtool makes the padding on all sides as well as the Y and
X axis mandatory. The image cannot be generated without them. (Not obvious from
my "image" is the fact that also the beveled frame around the image as well as
the right most logo also are included in all images).
WHAT I WANT FOR RRDTOOL 1.1.X
A user should be able to control what is included in the generated image. For
example, if a X-axis and a graph with curves is all that is needed, then the user
should be able to specify just those two components on the command line or in the
Perl interface.
To illustrate this, here's the resulting image:
+----------------------------+
| |
| Graph with curves |
| and areas. |
+----------------------------+
X-axis
But to make these things even hairier, I would like rrdtool to support multiple
graphs to be created and stacked on top of each other. For example, what about
several graphs with a X-axis at the bottom? Below is an example of three graphs
with an X-axis.
+----------------------------+
| Graph with curves |
| and areas. |
+----------------------------+
| Graph with curves |
| and areas. |
+----------------------------+
| Graph with curves |
| and areas. |
+----------------------------+
X-axis
WHY I WANT THIS
There is a certain type of graphs I would like to see support for in rrdtool
1.1.x.
The graphs I have in mind are "threshold graphs". A threshold graph isn't like
the normal graphs which take a 400x150 area and draw one or more curves/areas on
the graph. The threshold graph has normal width, but is much lower, perhaps 10
pixels so it forms a "bar". The bar's graphics show wether or not a certain
threshold condition has been met. The graph might be green for points in time
when the value is below a certain threshold and it might be red for values
violating the threshold. (You might also consider multiple colors and levels)
An ascii example is below where + = green and # is red and a space means "no data
available". In the image, an X-axis has been included.
++ + +++#+++####+###++++#+++++++++
X-axis
For an in and out value (which is the usual case in MRTG monitoring), you can
stack two such graphs on top of each other and put an X-axis below them to form
an image like this (more ascii...):
++ +++####+##########++###+++++++ (in)
++ ++++#+++####+###++++#+++++++++ (out)
X-axis
The purpose with these threshold graphs is to provide a quick "at a glance" view
of the status of a monitored value. So, these threshold graphs could be stacked
on top of each other to form compact index pages which provide a good overview as
well as an entry point to the monitored data. An example is given below. The
"-----" lines denotes a small padding of perhaps 4 pixels.
+++##################### ######## (in)
+++++++########+####++## ++###+++ (out)
----------------------------------
++++++++++#######+####++ ++++++++ (in)
+++++++++++++#++++++++++ ++++++++ (out)
----------------------------------
+++++++++++####+++++++++ ++++++++ (in)
+++++++++++++##++++#++++ ++++++++ (out)
----------------------------------
+++++++####+##########++ #+++++++ (in)
++++++++#+++####+###++++ ++++++++ (out)
X-axis
How to design the command line interface for the above image, I really don't
know. Currently, rrdtool just takes command line options to control the image
being generated. Perhaps the sed, awk and perl approach could be appropriate:
define a "script language" and then use that language either directly on the
command line or in a script file to define how the images should look like.
If anyone wonders if this really is useful I can say "Yes". I've created a
prototype which has been considered very useful by it's users. (No, I cannot
provide any demonstration for you folks. The enhancement to rrd_graph.c was too
much of a hack to be included in the RRDtool distribution, trust me.) The
problem with the prototype is that the above image with the four pairs of
threshold bars and one X-axis consists of 9 images which makes the loading of the
web pages SLOW. If they all were put into one page, it would be far better, as
it only had to be loaded all at once. Of course, the HTML code required to make
the right parts of the image map to the right MRTG collections become trickier,
but I think that would be worth it. (Of course, it must be possible to know on
what coordinates in the "big picture" different graphs are).
OTHER IMPLICATIONS OF CLIPPING
The RRDtool 1.0.x of today requires a number of arguments to generate the image:
* Some kind of data to graphs must be read from rrd-files and processed.
* Some kind of time span must be specified.
If clipping is in use, it might be unecessary to specify all these arguments for
the image to be generated. Assume that only an X-axis is wanted. If so, there
is no need whatsoever to provide any rrd-files or rrd-data processing code for
generating that image. However, a timespan is still necessary. Another case to
consider is if someone only wants the legend of the image or only the logotype
("RRDTOOL / TOBI OETIKER"). In that case, neither a time span or the
rrd-files/processing code is needed.
So, what do you think about this? I think it would be rather easy to incorporate
into rrdtool if it's kept into mind from the start. I know by my own experience
that it is difficult to incorporate it afterwards if the code isn't written with
these features in mind (I tried and managed to make it work with rrdtool
1.0.19). Of course, defining and implementing a script language for the images
could be tricky, but I think it could be well worth it.
Best regards
/IlvJa
Tobias Oetiker wrote:
> Folks,
>
> One of my goals for 1.1.x is to improve the rendering quality of
> the graphs created by rrdtool ... This means scalable fonts, anti-aliasing
> true scalability ...
>
> I can not see this being possible with libgd ... one way ahead
> would be to employ imagemagick. http://www.imagemagick.org either
> through its native drawing api
> http://www.imagemagick.org/www/api/draw.html
>
> Another possibility is using svg http://www.w3.org/Graphics/SVG/Overview.htm8
> together with an svg rendering library
>
> * imagemagick is said to posess some svg rendering capabilities
> * gnome nautilus contains librsvg
> * there is also http://xml.apache.org/batik/ but this seems to be
> done in java entirely which does not sound like something we can
> use.
>
> I find the svg route especially interesting as sooner or later we
> can expect all browsers to be able to render svg directly ...
> http://www.w3.org/Graphics/SVG/Overview.htm8
>
> Any thoughts on this? Anybody knows of good svg rendering libraries
> written in c ?
>
> tobi
>
> --
> ______ __ _
> /_ __/_ / / (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
> / // _ \/ _ \/ / TEL: +41(0)1-6325286 FAX:...1517 ICQ: 10419518
> /_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker
>
> --
> Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
> Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
> Archive http://www.ee.ethz.ch/~slist/rrd-developers
> WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
--
(Jakob Ilves) <jakob.ilves at oracle.com>
{Oracle Global IT, Network Management Group}
[Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572]
- Intranet Home Page: http://jilves.se.oracle.com -
-- Attached file removed by Listar and put at URL below --
-- Type: text/x-vcard
-- Desc: Card for Jakob Ilves
-- Size: 444 bytes
-- URL : http://www.ee.ethz.ch/~slist/pantomime/28-jakob.ilves.vcf
--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
More information about the rrd-developers
mailing list