Slashdot Mirror


Drawing Graphs on Your Browser?

Pieroxy queries: "I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...) for a web-based enterprise application. As we need some interactivity, the GIF image generated on the server-side is not an option. Here is the list of technologies I can think of: Flash is probably over kill and a closed technology. Java is very flexible but slow (to start and run). SVG (discussed here) still requires a plugin. VML is supported only on IE5+, but it is natively supported. Which one of these technologies is the more flexible and interactive? Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?"

35 of 201 comments (clear)

  1. Do you need all chart types, or just one? by TC+(WC) · · Score: 4, Insightful

    If you can get away with just bar charts, take several gifs/jpegs/pngs that are just single colour pixels and have your server-side program fiddle with the heights and widths to draw your bar chart without having the server generate an actual image file.

  2. IE5...not quite by X-wes · · Score: 5, Insightful

    Internet Explorer 5 and above are very widely-used. However, they are still flawed browsers and, due to the announcement that these browsers will no longer be updated as standalone applications, many people may switch to another browser. Also, those using a Unix-based platform (read: GNU/Linux) no longer have any viable way of using Internet Explorer. If it is not easy to change back and forth, the already limited audience VML will reach even less as time goes on.

    As an opinion only, if SVG is an option, it may be best in the long run. Assuming it is not easy to acrobatically jump from one option to the next (if that was possible, you could serve VML to IE 5.5+ and SVG to Mozilla, and some raster format for any other browsers), SVG holds the best promise. SVG is already supported as a plug-in (much like flash). It is about to be tested as a native part of the Mozilla browser. Over time, compatibility will actually improve--not something Java or VML can say easily. Also, as compatibility improves, simple scripting can make the charts interactive or real-time (or other neat fancy stuff).

    1. Re:IE5...not quite by Anonymous Coward · · Score: 2, Insightful

      IE5+ has too limited an audience to bother with, but Mozilla with SVG is worth the effort?!

      You sir, are incapable of consistant thought.

      You monkey.

    2. Re:IE5...not quite by rmohr02 · · Score: 3

      I would simply go with SVG. The first time I saw an SVG graphic on a webpage I was asked to download a viewer, and 30 seconds later I saw the image. That's not a real inconvenience.

    3. Re:IE5...not quite by syrinx · · Score: 2, Insightful

      IE5+ has too limited an audience to bother with, but Mozilla with SVG is worth the effort?!

      You sir, are incapable of consistant thought.


      And you seem to be incapable of any thought at all.

      Maybe you need this spoon fed to you.

      VML = only on IE5+

      SVG = on any browser with a plugin.

      Let's try that one again, just in case your brain hasn't quite wrapped itself around it.

      VML = not everyone.

      SVG = everyone.

      Get it yet?

      And I'd call *you* a monkey now, but that'd be an insult to many intelligent monkeys out there.

      --
      Quidquid latine dictum sit, altum sonatur.
    4. Re:IE5...not quite by aridhol · · Score: 2, Insightful
      The original post also said that plug-ins were inconvenient.
      However, the article mentioned Flash and Java, both of which require plugins.
      --
      I can't say that I don't give a fuck. I've just run out of fuck to give.
    5. Re:IE5...not quite by rmohr02 · · Score: 2, Funny

      This was about a year ago when I was still using IE (uggh). Anyway, Mozilla will probably have native SVG support by 1.5.

  3. I can answer the last two by Kris_J · · Score: 3, Informative
    Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?
    1) Require, no. Use for added functionality (interactive vs non-interactive) yes.
    2) No. If it doesn't work on (at least) Netscape/Mozilla then you're excluding too many people (unless you know something about your target audience that I don't).

    Surely you can do something with DHTML/Javascript to dynamically resize bar charts...

  4. JPGraph and PHP by FruitCak · · Score: 5, Informative

    I've recently had to do something very similar, well okay almost identical. Interactive graphs of various types and of various data sets from a Web Based interface.

    We have larges amounts of data which is very hard to interperate by a human in something like a spreadsheet. The only really feasable way to do it was graphs. Of course with the amount of data we had transmitting it to the client to do client side rendering (ie Java) is also out of the question.

    In the end we settled on JPGraph with an interactive interface built using PHP. So a wizard style interface to choose the type of graph, what data to graph, how to group the data, and finally the outputted graph with the option to change all the settings.

    With good indexed data making PHP generated graphs with JPGraph interactive is quite painless and very powerful.

    Just one suggestion, make sure you have a way for people to save the settings of the graphs they make so they can pull em later, keeps the PHBs happy :)

    --
    I'm me. I think.
  5. Client-side or server-side interactivity? by stoborrobots · · Score: 2, Interesting
    Do you need client-side interactivity (vis-a-vis an applet), or do you need a "dynamic image" (as used by most sharemarket websites, for example)?

    For serverside interactivity, a generated image (PNG,JPG,GIF) is more than suitable...

    You can even make it an imagemap, if you need image-based feedback...

    Just a thought...

    1. Re:Client-side or server-side interactivity? by Froggie · · Score: 2, Interesting
      On a slightly off-topic note, has anyone found a decent server-side graph generator? GD seems to be a bit pants, and almost none of them understand antialising...


      One option might be to find a server-side SVG renderer. Assuming you believe SVG will become an implemented standard (practically speaking, that means something that IE will eventually support) you could generate graphs in SVG, server-side render them for the time being, and have a relatively easy way of stepping forward to a SVG + JavaScript/DOM page in the future.


      Otherwise, if you want really clever ways of altering the graph's values or view that work today, you're going to have to use either Flash or Java.

  6. Why not an imagemap? by DrSkwid · · Score: 2, Insightful

    As we need some interactivity, the GIF image generated on the server-side is not an option.

    Surely an image with an onClick and some Javascript will do what you ask of it?

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:Why not an imagemap? by Froggie · · Score: 2, Interesting
      How on earth do you propose manipulating a bitmap image with "some Javascript"?

      By fetching another image when a change is requested, perhaps? This is easy enough to do without a page reload.

    2. Re:Why not an imagemap? by gazbo · · Score: 2, Insightful
      HAHAHA!

      Sir, you surely jest. Have you even considered the latency issues of a dynamic interface that requires an HTTP request every time something needs to be redrawn? Even on a gigabit network, with less than 6' of cable physically separating your client from the server it would be intolerable.

      You may as well say that Javascript should never be used as it can't do anything that can't be accomplished server-side.

  7. If it's meant to be this interactive.. by lpontiac · · Score: 4, Insightful

    .. and that interactivity is hard to achieve in a web browser, maybe this application doesn't belong in a web browser. Just a hunch.

  8. How closed is SWF really? by Burb · · Score: 3, Informative
    The SWF format is pretty open, as these things go. The FLA format used by flash is proprietary, but SWF documented and that's the bit that actually get's published on the page.

    The MING library can generate SWF from PHP et. al.

    --

  9. Flash isn't as bad as it used to be by Andy_R · · Score: 3, Insightful

    I've been pleasantly surprised by Flash MX, actionscript is a fully featured programming language that runs across all the platforms Flash is ported to. You can pass variables from your html page, so your graphing application should be writable as 1 single 'movie' that accepts data, rather than writing a new one every time you need to draw a graph.

    The only problem is that the tutorials and manuals are aimed purely at designers, not at programmers, so the concept of a variable is given a 20 page explanation whereas the syntax of the more complex commands is glossed over in a 'do this and it works, you probably don't need to mess with it' manner.

    --
    A pizza of radius z and thickness a has a volume of pi z z a
  10. Have you considered TABLE by Burb · · Score: 2, Informative

    For simple histograms, you can go quite a long way with TABLE TD and TR, and a few 1x1 coloured GIF files stretched to suit. Primitive perhaps but very portable to most browsers. OK, lynx users will get cross ... maybe generate ASCII art for them

    --

  11. Java might be faster than you think by dhk42 · · Score: 3, Informative

    If you want the interactivity, you should at least try an optimized pared down applet. It's true that most applets are slow, but it is frequently also true that they are written badly and/or contain heaps of additional libraries that they need to download. Use as much of java's built-in code as you can with the possible exception of the GUI library.

    Look at lightweight graphical libraries like lwvcl (commercial) or thinlet (LGPL) for the controls. The zaval people even have a charting library for their lwvcl system. (I have never used the lwvcl library, it just looks cool - try their online demo. Thinlet packs amazing capabilities into a very small package.)

    If you need to display 15 graphs at a time with limited interaction, then this may not be the way to go, but if you need to display one at a time with very rich interaction, this might be the ticket.

    dhk

  12. We use Corda by pbulteel73 · · Score: 5, Informative
    Most of these posts suggested image formats... I have a suggestion for an application if you want charts.

    Corda might do what you need. It will output the images in Flash, JPG, PNG, GIF, SVG and others. I believe it uses XML files to generate the graphs. I'm sure I'm missing a lot of the other things that it can do, but it's worth taking a look. Oh, and unfortunately it's not free, but it might be worth it if it does what you need.

    Note: I do not work for this company. I have seen the results of using their product. We use it where I work and everyone seems to like what it can do.

  13. Javascript by Basje · · Score: 3, Interesting

    I once wrote a piece of javascript that would do this client side. It was for a corporate intranet, so I knew which version of which browser was going to be used.

    The idea was simple: I created a table with every cell one pixel large, and set the colors accordingly to the input for the frame. It started out as a simple line graph, but in the end it could do bar and pies too.

    This should be doable crossbrowser now that JS has stabilized enough between IE and Moz. If implemented right, it can really do with much lower bandwidth than pictures (which was the main requirement then): the .js file can be cached, so only the data has to be sent, measuring a large multicolor pie graph in bytes rather Kbytes.

    --
    the pun is mightier than the sword
  14. Same problem by gazbo · · Score: 4, Insightful
    We're doing a similar type of thing, but not specifically graphs - arbitrary vector graphics are required, and client side is most definitely required. The route I went with was VML.

    There were a few options that I rejected:

    • Flash - probably extremely good at this sort of thing, as vector graphics and user interaction are its big target. However, we have no in-house expertise, and the end-users will all be professionals who may very well not have Flash installed (and furthermore, their firewall may not even give them HTTP access to download it)
    • SVG - Great! It's W3C approved, as opposed to the officially deprecated VML! Whoop-de-fucking-doo. When our clients complain that our application doesn't work, I'll point them to the W3C spec and have the warm glow of righteousness as all of the lawyers' letters demanding refunds come in.
    • Java - Well, it can handle drawing and events just fine, we have in-house expertise, but the whole point we're doing this through the browser is to avoid having to write an application from scratch in the first place. Now calling it an "applet" and changing main() to start() doesn't alter the fact that IMO writing user interfaces in Java sucks my grandma's clit.
    So, VML. We have the luxury of knowing that the standard desktop is Windows running IE. I suspect that at least 95% of your target desktops (you did say enterprise, right?) will be IE too. Furthermore, if they're running Windows then you know that even if they are running, say Mozilla, that they have IE to hand.

    At the risk of posting flamebait, do you really have to worry about the possibility of end users running a non-MS operating system? Almost certainly not. Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.

    Unless, of course, you do wish to use Flash and have the expertise - although I still think you'll run into issues of people not having installed the plugin.

    1. Re:Same problem by bill_mcgonigle · · Score: 2, Insightful

      Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.

      FYI, IE for Mac is a discontinued product.

      There's really little point in writing a Windows-only web site. I mean, if you're not going to be multi-platform, why hobble yourself with the web in the first place? A real Win32 app will be much easier for everybody.

      That he wants a web-based product is a good hint he wants multi-platform.

      To add some signal to the noise, I'm facing the same issue, and generating Flash from Perl is the approach I'm planning to investigate first.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  15. How about HTML and CSS? by DeadSea · · Score: 2, Informative
    Here's a mockup of a bargraph for a web site statistics package that I'm working on:

    http://ostermiller.org/bargraph.html

    It is done using only HTML with CSS. There was some reason that the bars come down from the top rather than up from the bottom, but I don't remember what it is right now...

    1. Re:How about HTML and CSS? by DeadSea · · Score: 2, Interesting

      Pie chart would be hard. I'll bet you could do a line graph. I'm thinking that you could generate a large table with javascript. You could set each each of the cells to be 1px by 1px. Then turn on the backgrounds of the ones in the line. It'd be a bit of a cludge, but it just might work. (Come to think of it, pie chart might work like this too if you have enough time on your hands).

    2. Re:How about HTML and CSS? by gazbo · · Score: 3, Interesting
      Cute idea - time to dig up the rasterizing algorithm and port it to JS. Yeah, in principle it would work (might possibly be a problem trying to persuade the browser that no, really, I honestly do want these TDs and TRs all to be on adjacent pixels.


      I wonder how quickly a browser could re-flow a document that included an 800X600 cell table...My guess is "painfully", but it's almost worth writing the concept code to find out - time to write some PHP (I'm buggered if I'm going to write it by hand)

    3. Re:How about HTML and CSS? by Pieroxy · · Score: 2, Interesting

      I actually gave it a try... 'twas too long this idea was in my head, so I tried it....

      My PC is approx. 1GHz.

      320x20 (yes, 320x20 not 320x200) pixels takes approx 1 minute to be built through DHTML. (Using a table and a TD for every cell). Giving that 320x5 takes 4 seconds, it is not linear and we can deduce that a 320x200 matrix would be built in a couple of days.

      Hmm, we'll need more than Hyperthreading.

  16. Ploticus by jedimaster101 · · Score: 2, Informative

    I rarely comment, but I can't help it here. I work for Wal-Mart, and I'm on a team that needed to be able to graph a system's performance (CPU/mem/network/disk usage, et cetera). Similar situation to what you're in, I think. I'm not sure what they were using beforehand, but everybody, managers included, is extremely happy that they've switched to Ploticus. They rave about how fast it generates a graph. It's very, very flexible. And it's open source; I noticed a subtle bug, and a few days after notifying the author he gave me a fix.

    We have the raw data points coming in from a server-side scripting language (proprietary, unfortunately). These points are passed to a Perl script which parses the data and stores it in a format Ploticus can recognize. It also generates the configuration file used by Ploticus.

    I'd really highly recommend Ploticus. No plugins needed. Once you figure it out, it's a dream.

  17. Agony of Expectation by 4of12 · · Score: 2, Insightful

    SVG to Mozilla

    A solid reliable freely-redistributable implementation of SVG, and in Mozilla, would be one of the finest things, IMNHO.

    A really good SVG implementation could make give web documents the elevated precision of presentation, akin to PDF, but in a W3C standard.

    With extensions such as MathML and dynamic SVG, the format could form the basis of not just web documents, but paper documents (eg, stuff that currently is done in Word, Quark, Framemaker, TeX), as well as dynamic presentations (eg, Powerpoint) and, simple interactive applications that are currently done in text boxes in JavaScript.

    Once a freely-available SVG renderer is available, then editing and composition tools for SVG documents should really take off. BTW, I don't count Adobe's SVG viewer because it is restricted to only a handful of platforms and no source is provided.

    From what little I understand, the Mozilla SVG effort has been a one man show and entangled in licensing clauses.

    It would be really nice if this were all cleared up and a big push into SVG by the Mozilla team were made.

    --
    "Provided by the management for your protection."
  18. SVG demo page -- including charts by XaXXon · · Score: 2, Informative

    Here's a link to an adobe site with SVG demos. If you look 4 down from the top, you'll find an interactive chart demo.

    I think this may be a good example of what you're looking for.

    In terms of support, if you plan on having this application around for a while, SVG is only going to get more popular.

  19. perl GD module by staplin · · Score: 2, Informative

    I've been using TWiki for collaboration notes, and one of its features is a plugin for charting. It manages to draw jpegs and pngs using the perl GD module and the gd library.

    Of course, you'd need to write your own server side to generate the chart you want, but these tools put you easily along that path.

  20. javascript vector graphics by JayClements · · Score: 2, Informative

    http://www.walterzorn.com/index.htm
    haven't used it, but the demo is fast and interactive.

  21. Flash once, data many by yelvington · · Score: 2, Informative

    Flash isn't just for animation any more. It's an interactive UI delivery platform.

    Write a generalized interactive graphing tool in Flash. Then have it fetch a simple data file (delimited text or XML) via HTTP.

    You can update the data dynamically and transmit the results with extremely low overhead.

    Flash kicks Java's butt when it comes to availability, reliability, predictability and performance. Flash on Linux is absolutely the same as Flash on Windows or the Mac. It just works.

    We have used Flash's ability to fetch dynamic data via HTTP to build "live" traffic and weather maps and perform other integration of constantly changing information.

  22. So in summary... by darnok · · Score: 2, Informative

    Putting together the responses to date, it seems like this is the story:

    SVG: lots of potential; the ideal solution if the plugin is installed or easily installable; XML based

    Flash: the pragmatic choice; installed nearly everywhere; works reliably on all platforms; can be driven via XML

    VML: good fit for IE 5+ browsers, since it's supported in a default install; unsupported in Mozilla; deprecated technology; XML based

    Java applet: slow to startup; JFreeChart looks very powerful provided startup times are acceptable and browser support is available

    In case you can't tell, I'm facing the same problem as the original poster. I also can't deploy server-side solutions, so PHP, Perl GD, etc are all out.

    Based on this, I'm inclined to build a generic XML solution, then rely on plugin detection and XSLT to deliver either SVG or VML as appropriate. That covers me for IE 5.5+ and anything with SVG support. The largest group that I don't have covered is Mac users and people with older browsers, and I could probably come up with a different XSLT to cope with them if the demand made it worth doing.

  23. To Clear the Air! by X-wes · · Score: 2

    First of all, seeing all of these flamebaits means one thing, and one thing only.

    I wasn't clear enough earlier. Sorry everyone!

    Okay, here's take 2:

    • Java and Flash require plugins (yes, Java VM, but you get my point)--on all browsers. Not fun.
    • VML: IE5.5+
      • But other browsers cannot use VML at all
      • If you don't use Windows, you cannot use IE 5.5+...therefore, all non-windows-users (including Macs!) will not be able to see the graphs
    • SVG: Mozilla ~1.5+
      • But other browsers can use SVG with a plugin, namely IE
      • Standalone IE production has stopped--many people will be looking for an alternative, and with Netscape gone, Mozilla is looking better than ever. Mozilla ~1.5+ -- no plugin for SVG needed!

    And of course the obligatory comments about how SVG is easier to script for. (More compatible: DOM/ECMAScript, etc.)