I’ve uploaded another teaser showcasing some of the work going into the CoFlo 0.0.5 release. The subject this time is the enhancement of the HTML reports CoFlo generates. See the live demo of the ongoing work here.
Note: The live demo works to varying degrees when run under various browsers. At the moment, both Firefox (16.0.2) and IE9 (32-bit, 9.0.8112.16421) seem to have no issues, while Chrome (23.0.1271.64 m) works to some extent, but for some reason puts some of the CFGs extremely far down on the page.
The goal of this part of the 0.0.5 work is to address a number of the issues present with the current static HTML reports, and to simultaneously provide more dynamic, interactive, and ultimately more useful reports.
The static reports generated by CoFlo through version 0.0.4 have a number of issues, two of which are:
- The Control Flow Graph images, in many cases, are dimensionally extremely large, often not fitting on the screen.
While work on the control flow graph generation engine will hopefully address this to some extent, it is unavoidable that many CFGs will, by their very nature, be too large to be meaningfully viewable as a static image on a webpage.
- All of the images are on a single HTML page.
The reports are basically a list of <img> tags containing the CFG images of each function in the single index.html file. This often results in one extremely wide image causing the browser to put a horizontal scroll bar with a very wide “throw” at the bottom of the page, making it difficult to precisely navigate the intermediate-sized CFGs. Also, having everything on one page makes for a poor user experience regardless.
Addressing the Issues
As I originally saw it, an interim solution which simply scaled any over-wide CFGs to fit the browser window would be more than adequate. Sure, there’d still be too many of them on one page, but vertical scrolling only would be far less onerous than both vertical and horizontal scrolling, and I could always split things up later into, say, one index.html and the one page per analyzed file. Furthermore, since this is the 21st century, how hard could this possibly be? Set a “max-width: 100%” somewhere and we’re golden.
Well, as it turns out: wrong. The first problem I ran into was that scaled PNGs look terrible. So I switched to SVGs, a vector graphics format, which is both well suited for the task and – after a mere 10 years or so - finally supported in the latest releases of all major browsers. Perfect! So now all that’s left to do is set that “max-width: 100%” in a CSS style sheet somewhere, check the results in the major browsers (if only out of an excess of caution, I mean really, what could possibly go wrong), and we’re done…
Wrong again. Worked as expected in some browsers, but on at least one other which shall remain nameless, it didn’t maintain the SVG’s aspect ratio. Turns out, that even in the 21st century – i.e. The Future(tm) – there’s no standards-specified way to tell a web browser “If this SVG <object> is wider than the browser window, resize it and maintain its aspect ratio”. So it was that I found myself entering the world of…
- The Same-Origin Policy
Short form: If you point your browser at files on your local filesystem (i.e. not through a server), your browser will block certain actions which it ordinarily wouldn’t. Need I mention that what is blocked varies wildly between browsers?
- The Dojo Toolkit
- There’s not really a standard way to include SVG files into HTML files.
There are at least three ways which work to varying degrees on different browsers, so I guess that’s something.
- You have to do a bit of DOM gymnastics to get an SVG’s ”naturalWidth” and “naturalHeight”.
As always, thanks for your interest in CoFlo.
Gary R. Van Sickle