Graphical TextScreen

Hi all.

I've been interested in JNode for quite some time and now I would like to participate. I'm currently using cvs head running in vmware.
Some weeks ago I bought a TFT monior with pivot function. And now, my main motivation is to be able to use the pivot function in JNode. Therefore I would like to implement a TextScreen using FrameBuffer and not the native console mode. The advantages would be:

• pivot support
• full unicode support
• mousecoursor support
• other architectures with fbdev only

To achieve this, I have some proposals:

I would like to have an extension in FrameBufferConfiguration with a new variable, like:

private final int rotation;

and some constants

private final int ROTATE_NORMAL = 0;
private final int ROTATE_90 = 1;
private final int ROTATE_180 = 2;
private final int ROTATE_270 = 3;

Then the driver can decide, whether it supports rotation or not, via the getConfiguration()-method. Also the Surface and AbstractSurface could implement the behavior for rotation, if they just modify the drawPixel-method to regard the rotation-flag. (For reference: Linux uses the RandR extension, but most driver don't support it)

Then I would implement a TextScreen, which uses FrameBuffer and could therefore support rotation also in textmode. So, a second idea would be to extend the abstract TextScreen for some new methods

public TextScreen createCompatibleBufferScreen(...);

with some parameters to set the size of the TextScreen and if it is rotated or not. Also it would be possible to have a 'decorated' TextScreen like in Linux, so you always have the JNode logo on top.

After this, all letters would be 'rendered' via FrameBuffer on the screen. That means it could be done with Glyphs beeing GeneralPath and these would be painted to the Surface. But since all letters have the same size and many are painted more than once, there could be a better way. So I thought of having a byte[] (and ByteBuffer respectively) which just keeps the values to be written into memory. The graphics drivers all have in common a MemoryRessource to which will be painted via the setByte() methods. To improve this, I had the idea of adding a new class: class Sprite. This class represents a rectangle with color values. There could be subclasses Sprite8bpp, Sprite16bpp,... for the different color depths to respect the memory layout. To take advantage of this class, the class Surface would need a new method to draw Sprites like:

public void drawSprite(Sprite s, int x_offset, int y_offset)

The implementation of the method should than take advantage of the Sprite's layout and just copy one line after the other to the MemoryRessource with arraycopy. This could also help to make window movements draw faster on the screen if in graphics mode.

So as you see, I could implement the TextScreen without the possibility for rotation support. Rotation support isn't needed but it would be cool and the earlier there is support for it, the better it will be integrated in the future.
Also the Sprite and drawSprite things aren't needed since I could paint letters via GeneralPaths or just draw the single points. But I think the Sprite method could speed up things and allow for optimisations (also native via driver). Sprite could for example extend ByteBuffer, what could give further speed.

So my questions are:

• Do you like the idea of a TextScreen with Framebuffer support?
• What do you think about rotation support?
• What do you think about the Sprite proposal?
• How should I achieve, that TextScreen gets more options (like resolution, logo displaying, rotation,...)? So should there be a new class TextScreenConfiguration, which keeps the configuration?

  Something like:

  int rotated;
  Sprite screen_decoration;
  int width; // in characters
  int height; // in characters
  FrameBufferConfiguration fbConfiguration; // keeps fb resolution,...

I would be nice to hear from you,

Peter