First, let me thank you for your response. I'm about to dismiss your suggestion, but I hope to show that I'm not doing so without due thought and consideration :)

Move up to Gtk2. ;-) Perl/Gtk2 will accept binary data for images,

The first problem is that despite several attempts, I've never managed to get GTK* to build here. The last time I attempted it, I was using 32-bit and it failed hard. I have no expectation that it would be any easier for my 64-bit setup.

But even if I could, it still doesn't answer most of the problems I have with such toolkits. Which essentially comes down to the fact they take over the whole application, forcing a particular (and abhorrent:) structure, and side-lining the raison d'etre for the applications existence.

For the type of applications I'm describing, there purpose in life is to generate and.or process large amounts of data. They are just command line apps that you fire off into the background and forget till they are done. But sometimes, especially during development, I want to be able to visualise what they are doing. Because they are dealing with large amounts of data, producing huge swaths of trace output--just reams and reams of numbers--is effectively useless, because the detail gets lost in the noise.

That's where the visualisation comes in. If you can throw a few lines or dots or blocks of color into an image and 'flicker compare' two different algorithms; or sequential iterations of same algorithm; the human brains uncanny ability for pattern recognition--hardwired and tuned over millions of years of evolution--can often detect patterns, trends and anomalies in huge amounts of data, that would be weeks of work to detect by looking at the same data represented as reams of numbers.

But the visualisations are not the primary purpose of the applications. Or even a required part of the final programs. They are just a transient part of the development process. The are effectively just a debugging aid, used in much the same way as Data::Dumper, for a quick check of what the program is doing to or with the data. And just like Data::Dumper debug lines, once the program is working correctly, they should be easily either disabled, or remove completely from the program. Their purpose served.

You just can't do that with a GUI toolkit.

Also consider if you are using Firefox, IT itself uses Gtk2 based widgets, so why deal with javascript and all that mess? Just write your own app. :-)

Why write an app when I have a browser that can already do everything I need? And more importantly, everyone has a browser. So if I want to share my visualisation with someone else--as in the OP of a question I am responding to here; or my brother in the states--they only have to install the BUI module (not a real suggestion for a name)--which should have no need for non-core dependencies and run anywhere perl does--and download the code I post and run it.

No need to have to seek out and download 27 billion dependency libraries spread all across the web and work out how to try and build them all together as is the case wth GTK* and similar.