setMapDirect results in UnsupportedOperationException

[crinklywrappr]

Apologies that this bugreport is told almost entirely with pictures. I don't have gpm set up yet, so I can't copy text from the VT.

Seems it doesn't like your call to asIntBuffer here.

Stacktrace

Demonstration

Code to reporoduce

(defn draw2 []
  (with-open [fb (FrameBuffer/getFrameBuffer "/dev/fb0")]
    (.setMapDirect fb true)
    (doto (. fb getGraphics)
      (.setColor Color/RED)
      (.drawRect 0 0 800 600))))

[brett-smith]

Sadly, it turns out that is just not possible.

It's been a long time since I looked at linuxio4j (it was written for a product I worked on that now just receives the occasional maintenance), and usage of a direct ByteBuffer it turns out was never completed, probably because of how hard it is ;)

The problem is because we are using a BufferedImage as the most convenient way to provide a graphics context to draw on. This in turn requires a DataBuffer, whose backing array we attempted to use the ByteBuffer.array() for. It turns out a memory mapped file will not return an array in this situation.

I made an attempt to use a custom DataBuffer which writes to the ByteBuffer directly, but this turns out to be about 5 times slower than the non-direct ByteBuffer and copying the contents of each frame each time. I am pretty sure this is because of the structure of DataBuffer, that will have DataBuffer.setElement() called width X height times instead of just copying a chunk of memory.

All I can do for now is make it clear that you cannot get a BufferedImage to draw on if using a direct buffer, instead you must access the ByteBuffer yourself and 'draw' on it byte by byte. It may also be possible to use an external library to do the drawing directly, but this is out of the scope of this library really.

I am open to suggestions if anyone out there knows of another way to do this.