1

This is my very first attempt at generating images on the fly.

I want to display around 500 small -- say, 32px X 24px -- 16-color images, each in a table cell. Each image (as I see it now) is a 2D array of colored pixels, each representing a value furnished by C-language CGI.

The finished, displayed image is a prmitive candlestick graph, each candle one pixel wide, something like: http://www.sellmycalls.com/pics/candle-sample.png

All of the ~500 images want to be available for redisplay every 10 seconds, although:

  • only around 30 of these guys show up in the viewport at any instant; and
  • the images change only every ~10 minutes.

I can generate the images on any combination of the server and the client. But I need a general strategy to get me started.

What's the lightest-weight (no huge JS lib, I hope), quickest (implementation), fastest (execution), and cheapest (client-side RAM) to get these images displayed?

Thanks!

Pete Wilson
  • 8,610
  • 6
  • 39
  • 51
  • 2
    Consider that downloading 500 seperate small images will by far outweigh the one-time cost of downloading even a "large" JS library. A minified copy of jquery is around 100k, and you'd probably have around 500k of image data. jquery would be a one-time donwload, while you'd have to regrab all 500+ images every 10 minutes. – Marc B Jun 01 '11 at 16:07
  • @Marc B -- yeah, that's right. Thanks, Marc. – Pete Wilson Jun 01 '11 at 16:10
  • 1
    @marc: acutally minifed jquery is 31kB – dynamic Jun 01 '11 at 16:17

2 Answers2

4

If you ask me what is the

  • fastest
  • quickest
  • cheapest

I have no dubt about it:

http://code.google.com/apis/chart/

You can delegate all the dirty job to google' server.

And that's not bad at all.

dynamic
  • 46,985
  • 55
  • 154
  • 231
  • @yes123 -- but then doesn't the user have to wait forever for google to come back with these things? How can I mitigate that delay? – Pete Wilson Jun 01 '11 at 16:02
  • @pete: have you tried the stunning speed of the generation? https://chart.googleapis.com/chart?cht=lc&chs=400x240&chtt=Yearly%20Expenses%20and%20Sales&chxt=x%2Cy&chxl=0%3A|2004|2005|2006|2007&chdlp=r&chdl=Expenses|Sales&chco=3399CC%2C80C65A%2C00000000&chxr=1%2C300%2C1400&chm=b%2C3399CC%2C0%2C1%2C0|b%2C80C65A%2C1%2C2%2C0&chd=e%3AotymU8qd%2Ci5otRcot%2CAAAA – dynamic Jun 01 '11 at 16:05
  • @yes123 -- and you think google is going to be pretty quick, even with 500 of these suckers? – Pete Wilson Jun 01 '11 at 16:08
  • @pete: you must be kidding I believe... http://searchenginewatch.com/article/2067276/Searches-Per-Day (from 2006) – dynamic Jun 01 '11 at 16:10
  • @pete: Anyway if more users request the same images you can still add a cacher layer between google and your users so you can cache the image sent you by google and not having to request always the same images on their servers – dynamic Jun 01 '11 at 16:11
  • @yes123 -- can you give me a quick pointer to the details of a cacher layer? Like, where does this layer live? On my server? Or somehow, somewhere in the client? – Pete Wilson Jun 01 '11 at 16:18
  • Which is your server side language (I hardly believe you use plain C for a web app)? Anyway this is completly another question don't you think? – dynamic Jun 01 '11 at 16:19
  • @yes123 -- since I have grabbed you by the arm, it seemed a good time to ask that off-topic question :-) Yes, I'll post that as a new question. The server-side language is C. – Pete Wilson Jun 01 '11 at 16:21
  • @pete: OH MY can't believe you use C XD. Anyway if this answer helped you think to pick it. Thanks – dynamic Jun 01 '11 at 16:22
  • @yes123 -- and, instead of C, your suggestion is ... ? I'm very interested to see your response. – Pete Wilson Jun 01 '11 at 16:35
  • @pete: my suggestion is **personal** because I simply love it.. PHP. But If you need pure Speed than a plain old c/c++ can't be beaten – dynamic Jun 01 '11 at 16:38
  • @yes123 -- personal opinions and suggestions are the *only* ones that have any strength and value, imo. Anyway: yes, speed was the criterion. Server code has to catch, parse, and format streams of real-time data. And it all has to be secured: I questioned the rightness PHP in that environment. Thanks for your opinions! – Pete Wilson Jun 01 '11 at 16:47
  • @yes123 -- please take a look at my "cacher layer" question: http://stackoverflow.com/questions/6204569/cacher-layer-for-google-generated-images – Pete Wilson Jun 01 '11 at 16:51
1

Another option should be to simply use Canvas. Simply draw each candle onto the canvas according to to the values generated by your C CGI. You can fetch those values through a simple AJAX call into the client.

No JS library required. The canvas API is trivial, a few lines of code will generate your images. It should execute fast enough so that the user won't even notice they are generated dynamically (that is 30 images / viewport). And it is not much more expensive than displaying static images for the client RAM and also will not produce any additional load on your server.

Daniel Baulig
  • 10,739
  • 6
  • 44
  • 43
  • ok, yes, I see. I'm demanding that visitors have an html5 browser anyway, so why *not* canvas? – Pete Wilson Jun 01 '11 at 16:17
  • 1
    One reason why you might not want to use Canvas could be that you actually do not want to burden the client with the generation of the images, because you expect mostly (or exclusively) mobile / thin clients like smartphones. – Daniel Baulig Jun 01 '11 at 16:51