1:49pm, Chad Gard wrote:
Thanks for tips/pointers, all.
I was unable to make the graphs consistently small enough to use the data url
scheme that David pointed me toward. For now, I opted for passing enough off
to another script to make another database request. It's causes several
redundant S
Thanks for tips/pointers, all.
I was unable to make the graphs consistently small enough to use the
data url scheme that David pointed me toward. For now, I opted for
passing enough off to another script to make another database request.
It's causes several redundant SQL queries, and further c
> >Yeah, though then I have to worry about cleaning up the temp directory,
> >and I'd like to avoid unnecessary writes to the hard drive (to avoid
> >directory damage possibilities, energy use, fragmentation, etc). It
> >logically makes sense to just send these things out as they're generated.
> 11:03am, Chad Gard wrote:
>
> >
> > On Jan 21, 2005, at 10:22 AM, Sean Davis wrote:
> >
> >> You could also have your main script generate the images all at
once (at
> >> the same time as you are generating the HTML), put the graphics in
temp
> >> files, and then put the appropriate URLs in th
11:03am, Chad Gard wrote:
On Jan 21, 2005, at 10:22 AM, Sean Davis wrote:
You could also have your main script generate the images all at once (at
the same time as you are generating the HTML), put the graphics in temp
files, and then put the appropriate URLs in the img tags. This will
eliminat
On Jan 21, 2005, at 11:03 AM, Chad Gard wrote:
On Jan 21, 2005, at 10:22 AM, Sean Davis wrote:
Do these need to all be generated on-the-fly? Or is there a way to
create them first (one time a day, for example) and serve them as
static images?
They need to be generated on-the-fly, as the data cha
On Jan 21, 2005, at 10:22 AM, Sean Davis wrote:
Do these need to all be generated on-the-fly? Or is there a way to
create them first (one time a day, for example) and serve them as
static images?
They need to be generated on-the-fly, as the data changes continually.
You could also have your mai
Chad Gard wrote:
> and I really don't want to write images to files on disk.
I think you should reconsider. This is really your best bet. Web clients and
servers are really optimized for this kind of thing. You should write all
the images out to disk files accessible through URL's and then emit IM
On Fri, 21 Jan 2005, Chad Gard wrote:
> That's what I'll do if I can't make it work the way I want. However,
> I'd like to be able to avoid the overhead of additional queries, and
> additional browser connections to the web server. I already get all
> the data I need for other parts of the pa
On Jan 21, 2005, at 10:05 AM, Chad Gard wrote:
On Jan 21, 2005, at 9:56 AM, David Dorward wrote:
How about passing it the data it needs to make a suitable database
request?
That's what I'll do if I can't make it work the way I want. However,
I'd like to be able to avoid the overhead of additional
On Jan 21, 2005, at 9:56 AM, David Dorward wrote:
How about passing it the data it needs to make a suitable database
request?
That's what I'll do if I can't make it work the way I want. However,
I'd like to be able to avoid the overhead of additional queries, and
additional browser connections t
On Fri, Jan 21, 2005 at 09:43:40AM -0500, Chad Gard wrote:
> I have a CGI that generates a page from data in a database. I want to
> include several graphs of data in the page.
>
> I can use GD::Graph to create the images. But, the data sets are
> rather large/awkward to try to send off to ano
Hello, all.
I have a CGI that generates a page from data in a database. I want to
include several graphs of data in the page.
I can use GD::Graph to create the images. But, the data sets are
rather large/awkward to try to send off to another CGI that I could use
with the IMG tag, and I really
13 matches
Mail list logo
