Merge CacioWeb

[Richard Bair]

On Jan 5, 2012, at 12:20 PM, Roman Kennke <roman at kennke.org> wrote:

> Hi all,
> 
> Thanks Mario for bringing this up.
> 
> First of all let me explain what is Cacio and why we think it's useful.
> In essence, it is an (somewhat) abstract implementation of AWT peers. It
> implements all the AWT widgets by using Swing for painting and
> event/logic processing. This reduces the burden of porting/implementing
> the Java graphics stack enourmously. Currently, when one wants to port
> the Java graphics stack, the AWT peers need to be implemented as well,
> for compatibility. This is a huge effort, and considered rather
> pointless by many, because AWT is not that widely used anyway. It is
> particularily difficult on platforms that don't have any native widgets
> (most embedded platforms). Using Cacio, this effort is reduced to
> implementing a Java2D backend and some basic windowing functionality. It
> even provides a windowing implementation in Java for platforms that
> don't even support windows (e.g. framebuffers).

Funny thing, I believe the Mac OS port uses this same technique. Does anybody know what the differences are between the two?

> We also have a somewhat special backend which renders
> exclusively into a BufferedImage and can only process events generated
> by Robot, which is particularily useful for unit testing GUI
> applications without messing around with the user's desktop or without
> requiring graphics on a continuous integration server (extremely useful
> if you're into this GUI testing thingy).

That would be very cool. The SQE team uses robot / image testing heavily for FX and "taking over my computer" is one of the chief problems with it (the other being image tests are finicky).