34 lines
4.0 KiB
HTML
34 lines
4.0 KiB
HTML
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>What you can do with the library</title><link rel="stylesheet" type="text/css" href="manual.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.0"><link rel="home" href="index.html" title="JpGraph Manual"><link rel="up" href="ch01.html" title="Chapter 1. About the library"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">What you can do with the library</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center">Chapter 1. About the library</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="What you can do with the library"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2472677"></a>What you can do with the library</h2></div></div></div>
|
||
|
||
<p>One should probably differentiate between the two basic usage scenarios</p>
|
||
<p>
|
||
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">
|
||
<p><span class="bold"><strong>Online.</strong></span> That is, the image is dynamically
|
||
generated when a user is viewing a particular WEB-page. This means that
|
||
the time it takes to generate the image will add to the delay the user
|
||
is experiencing when trying to view the page. (The library supports a
|
||
caching mechanism to reduce the number of times an image has to
|
||
generated, see <a class="xref" href="ch05s06.html" title="Efficient graph generation using the built-in cache subsystem">Efficient graph generation using the built-in cache subsystem</a> for a thorough
|
||
discussion). For this scenario one should probably keep the images as
|
||
basic as possible in order to have as small latency as possible. </p>
|
||
<p>In practice this means that the number of data points to visualize
|
||
should be kept in the order of hundreds and not thousands. In later
|
||
sections we will discuss in details what can be done to improve the
|
||
performance of the library.</p>
|
||
<p> </p>
|
||
</li><li class="listitem">
|
||
<p><span class="bold"><strong>Offline</strong></span>. That is, the images are generated by
|
||
some "batch" processing (possible command line based). In this scenario
|
||
the delay is not an issue and one could create much more complicated
|
||
images and process many more data points. Even though the library in
|
||
itself does not impose any restriction of the number of data points to
|
||
process the memory and time limits set for PHP will. </p>
|
||
<p>In practice if you need to process images with sizes above 2000x2000
|
||
pixels resulting from processing 500,000 data points then it is probably
|
||
better to find a more suitable way to produce these graphs rather than a
|
||
PHP script (unless you are prepared to give PHP a couple of 100 MB of
|
||
allowed memory)</p>
|
||
</li></ol></div><p>
|
||
</p>
|
||
</div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"><a accesskey="u" href="ch01.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
|