Yes, you should plot them all to a single large image, otherwise a single client displaying the page will result in 100-500 requests to your webserver. Even all load and performance put aside, it means the page will take a while to display even if you're hitting the server locally over the loopback interface.

All of the graphics generation modules support printing the result to any filehandle you wish, incl. STDOUT, and thus directly to the browser.

I also suggest you take a look at Imager and Imager::Plot instead of GD.

Makeshifts last the longest.

Have you considered gnuplot for this? That link is to perl interfaces on CPAN.

After Compline,
Zaxo

Do your little circles have to be re-generated each time the script is called? Ie. If the circles are always the same size(s) and chosen from a limited set of colours, and it's only which colour/size get displayed in which position each time, then you are probably better off generating 1 small gif/png of each possible color/size combination and placing these somewhere accessable to your cgi script as a one time thing.

Then, your cgi script need only calculate which of the pre-existing images needs to be displayed in each position and generate the html with the appropriate IMG tag in each position. Saves (re-) generating the images each time. You could do this with image tags inside a table--quick and simple but not hip. Or you could use css to position the images.

Perhaps the smartest way would be to use css to define classes for each color/size combination using the background-image property, and then generate a table with the appropriate class applied to each cell.

Theoretically you could have a standard table with a different class tag applied to each cell (eg. <td class="cell0-0"></td><td class="cell1-0"></td>...) and then you generate the style sheet to map the class definition (eg.  cell0-0 { background-image: url( 'images/bluecircle.png'); } etc. as required by your calculations.

If however, there is no reasonable finite set of colour/size combinations, then your probably better of generating one large image, writing it to disc with a unique name and then generating the html to reference the image you generated. Doing it this way you will need to have some mechanism for cleaning up the (possibly large in size and number) of the images you generate.

A clearer description of your application and your code so far will usually get you better responses.

Minor comment about your CSS idea: CSS is for style, not substance. The page should still be readable (even the table of visual data) without the CSS page at all. It's not just a way to shortcut wordy HTML, it's a way to let the HTML focus on the substance.

--
[ e d @ h a l l e y . c c ]

To some extent I agree with you, but as I don't know the nature or use to which the little circles are being put, I find myself reluctant to make a judgement about the correct way to display them.

There is the view point that no form of graphics or imagery should be used as content as

1. This denies access to the content to the blind
2. It prevents the content being accessed by users of text-only browsers like lynx.

There is also the fairly prevelent opinion that using tables for positional purposes is wrong. It is this usage that the CSS positional attributes are designed to supplant. However, if one attempts to render all content without any dependance upon positioning, many types of information simply become extremely difficult, or impossible to present. For example: Trying to render complex mathematical equations -- where subscripts can have superscripts and superscripts subscripts and either or both of the superscripted subscripts and the subscripted superscripts can themselves have either subscripts or superscripts, and so on -- becomes impossible without the ability to either position these accurately, or resorting to rendering them as inline graphics, which breaks when text-only browsers are used.

If you accept that stylesheets have a legitimate use in presenting content, as well as for styling that content, and that it is legitimate that some or all of the value of the content will be lost if the associated stylesheets are overridden or ignored, then using stylesheets as another programmable element of the content rendition is also legitimate.

I too have often wished that all content on the web were accessable in textual form, free from browser-dependant, browser-side programming, slow-to-render tabular and 1-pixel gif positioning, and screen-size dependancies. And as a forced-upon-me-by-my-location, dial-up user with rarely better than a 40k bps connection, I often dispair of web pages/sites that take forever to render because of pointless, excessive use of graphical and dynamic content. However, here are many types of content that are simply better represented using graphical content and/or the spacial relationship of text.

There is also a considerable amount of truth in the adage that a picture paints a thousand words, and as far as web content is concerned, as the bandwidth becomes available, and provided the infrastructure can be enhanced to keep pace, then I think that we will rapidly see the "thousand words" in that become subject to Moore's law. Visit HowStuffWorks site for some really good examples of this. And, if you have seen some of the things that can be done using graphics in various fields that traditionally were text-only and/or numeric-only disciplines, then you might agree with me.

I was recently privaleged to preview an application that used a 3D representation of the words used by an author, plotted against their frequency of use, with the third axis being the chronological order of authorship of the pieces being examined. This depiction of the evolution (or lack thereof) of the authors language over time is fascinating. It was even muted that given sufficient samples, it would be possible to place a piece work known to be by the same author, but from an unknown timeframe, within the chronology with some considerable accuracy. Whilst it might be possible to present this kind of correlation using a large table of numbers, the use of graphics can make any discontinuities in trend analysies of this type, literally, 'leap out' at the observer.

There was also some speculation that projects like Eschelon (if it really exists:), could use word frequencies, particularly of uncommon words, overlaid geo-globally using source/destination ip information to find and track hotspots and hot routes of "interesting" net traffic. Again, numeric presentation would contain the data, but graphical presentation can turn that data into information.

Even which something as lowly as the presentation of code, the addition of graphic information, in the the form of colored syntax highlighting can add content. I realise that some completely reject this notion, and the ability for those people to ignore that additional information by disabling the stylesheet that effects it is desirable.

Personally I think that ideas that all web content will be fully accessible from all browsers, regardless of the browser type, screen size & capabilities, or the visual & aural acuity and preferences of the 'viewer' are forlorn (and in many cases a little ludite). The only way for this to be a reality is for the many to accept the lowest common denominator of the capabilities and desires of the few. And the idea that content can always be divorced from style, equally so.

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

• pie charts
• bar charts
• histograms
• box & whisker charts
• linegraphs
• pointgraphs (scatter graphs)
• areagraphs
• candlestick graphs
• Gantt charts
• quadtree graphs

#!/usr/bin/perl -w

use strict;
use GD;

my $image = new GD::Image(468,60);

. . .

print "Content-type: image/png\n\n";
print $image->png;
[download]

      
--------------------------------
SV* sv_bless(SV* sv, HV* stash);

Note: This is update my previous post
I'm sorry I've forgotten define lins on graphic modules:
• DBD::Chart
• DBIx::Chart

      
--------------------------------
SV* sv_bless(SV* sv, HV* stash);

If you can make do with the layout restrictions of a table, then you can actually produce circles without generating each of them dynamically. The trick is to use only one graphic, which is opaque on the "outside" areas, filled with the color of your page's background, and has a disc-shaped transparent area punched out in the center. If you place this image in a table cell with a background color set, it will give the appearance of a disc filled the table cell's background color.

Makeshifts last the longest.

Hi there, Do you absolutely HAVE to use circles? Because if not, then you could create a table, and just fill in specific cells with specific BG colors. Your colors would be squares (or rectangles), but the download time would be much faster than rendering each graphic. Just an idea. -n8