Escher ideas

During the last couple of weeks I worked on Escher only every now and then. I re-architectured the protocol implementation so that the object creation is minimized. Before this change Escher created one small array per request, which can have a pretty noticable impact when rendering. Now there is only one buffer into which all requests are written. This brings a pretty nice performance gain. I’m finishing this step off now (this will take another couple of days or weeks even). However, I’m happy that I have a little more spare time now (finished the study, yay!) and can continue on Escher with more drive now. Here’s a bunch of ideas what I could do in the future:

  • Avoid even more potential copies by using NIO channels. A socket implementation might require copying the passed-in byte[] on the native side. NIO channels allow to pass in a ByteBuffer which can be backed by the correct native data structure already, thus avoiding the need to copy the buffer from a Java array to a native array. Going the NIO route seems to have a couple of other advantages too (e.g. avoid polling for inbound traffic).
  • Right now, Escher is made to be completely thread safe. This is basically the same mistake as was designed into AWT. The problem is that many applications don’t need this thread safety at all and could rather implement single threaded rendering and avoid acquiring locks altogether. Another point here is that applications that do render using multiple threads usually can do the locking much more efficient, e.g. acquire a lock once, render a complete frame (or some other logical unit) and release the lock once, rather than acquiring and releasing the lock on each little graphics primitive. The plan here is to drop thread safety on outbound X traffic (e.g. rendering) and only protect inbound traffic (because this is most often handled by a separate (event) thread anyway AND the main thread (for X replies).
  • Make Escher implement the JOGL interfaces ( This way, Escher could be used as a direct replacement for the standard JOGL implementation on X based systems. It is my hope that this implementation is at least as efficient as the original JOGL one, or even more efficient because native calls are avoided altogether (or at least, performed more seldomly, that is when the buffer runs full and is flushed to the network).
  • Add tesselation (and other utilities). Without tesselation, OpenGL isn’t able to render complex shapes at all. This feature can most likely be provided by the plain JOGL classes and don’t need to be rewritten. This would go hand in hand with the previous point.

Furthermore, I hope I can put more work into the Escher based AWT peers and polish them up for real use. Most importantly, this requires better TrueType font support (by the Java font impl in GNU Classpath), better AWT widget support (by the Swing backed AWT widget set) and a shitload of bug fixes in the peers and Escher itself.


About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: