Ian,
Removing the dimension tags in the template was the first thing I tried. It
indeed stops the elements from being resized from their native dimensions,
but at the cost of having the graphs be different sizes, which IMO looks
silly. I think having the dimensions be configurable in pixels in the
template file is a good customizability fix and lets the
users/administrators decide for themselves what the graph sizes are. The
double call to RRDTOOL is only necessary because RRDTOOL doesn't have an
option to specify the size of the output image, and I think that is an
oversight on RRDTOOL's part. RRDTOOL should not dictate to the user what
the image size is (or make the user have to RRDTOOL multiple times to adjust
the canvas dimensions so that the final dimensions are as desired). I will
send a message to the rrd-users mailing list and see if they've got some
better way to accomplish this. The /dev/null thing is also quite annoying,
I agree. Unfortunately I couldn't figure out any other way to capture
--imginfo dimensions while still throwing away the actual graph output.
-Matt
_____
From: Ian Cunningham [mailto:[EMAIL PROTECTED]
Sent: Monday, May 07, 2007 2:38 PM
To: Matthew Chambers
Cc: [email protected]
Subject: Re: [Ganglia-developers] Web frontend graph sizes
Matt,
I'm not sure I like the idea of outputting to /dev/null, it seems like we
will be making the web server twice as much raster work and increasing the
load unnecessarily.
Also I thought this problem had already been solved by removing width and
height attributes from the img tags, in web frontend version 3.0.5, but I
could be mistaken.
Cheers,
Ian
Matthew Chambers wrote:
Hi all,
I recently started using Ganglia on our Mac Mini cluster and I noticed that
the graphs are resized from their native size so that they fit the
templates. This didn't make a lot of sense to me, so I edited the system so
that the images returned by graph.php calls are used as-is. I added two
variables "sx" and "sy" which are passed in the graph.php call specifying
the desired width and height of the output image. This approach means that,
at least for the image calls which are fully specified from the templates,
the dimensions can be specified in the template and needn't be worried about
anywhere else. When I made this modification I discovered that the width
and height that rrdgraph takes are actually the dimensions of the canvas
(the inside box that the actual graph is plotted on), and they don't include
the outer box. Rrdgraph does provide a way to get the final image's
dimensions (--imginfo), but it is not possible to use it while also using
the standard output mode (which is what the graph.php call does). So I
added a second call in graph.php which writes to /dev/null and simply parses
the output dimensions and adjusts the dimensions given to the second call by
the amount necessary to make the final dimensions match the "sx" and "sy"
variables. Since the "z" variable is obsolete but was still used to change
the graph style slightly for the host graphs, I changed it to a "formtype"
variable ("f") with values of "compact" or "normal." Oh, I also changed the
images to PNG instead of GIF since the rrdtool documentation says that PNGs
are generated as fast or faster and are as small or smaller than GIFs.
Here's the code:
#
# Generate the rrdtool graph command.
#
if ($formtype != "compact")
{
$command = RRDTOOL . " graph /dev/null --start $start --end $end
".
"--width $width --height $height $upper_limit $lower_limit ".
"--title '$title' $vertical_label $extras $background ".
" --imgformat 'PNG' --imginfo '%s\n%lu %lu' ".
$series;
$imginfo = exec($command);
$dims = explode(" ", $imginfo);
$width = $width - ($dims[0]-$width);
$height = $height - ($dims[1]-$height);
}
$command = RRDTOOL . " graph - --start $start --end $end ".
"--width $width --height $height $upper_limit $lower_limit ".
"--title '$title' $vertical_label $extras $background ".
#"--imgformat 'PNG' ".
"--step 5 ".
$series;
There are a few problems with this approach: 1) /dev/null is platform
specific (are there other parts of Ganglia that are already platform
specific so that this isn't such an issue?); 2) if the layout of the graph's
legend changes when the dimensions are adjusted, the adjustments won't be
correct, and I'm not sure what the best approach is to fix this. Let me
know what you guys think about this approach. If it's satisfactory, I'll
submit the changes to the repository.
Also, has there been any discussion about using SVG instead of raster
formats for the graph output? It would introduce serious user agent
compatibility considerations, but it would provide quite a lot of potential
benefits (interactivity, anyone?). Rrdtool's SVG output would need to be
improved, though.
Thanks,
Matt Chambers
_____
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_____
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
