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>
|