Graphics framework

This is where the graphics framework requirements & specification will come.



Current project members:

  • Valentin
  • Levente
  • Nathan



My current thoughts on the graphics framework is that the graphics driver is passed the basic hardware resources it needs. It cannot access any other hardware resources.




The driver needs to provide a list of supported video modes, resolutions and refresh rates. The driver might also provide infromation about the attached video display device. E.g. flat panel, resolution, make model refresh rate etc.




There needs to be a standard way to query the driver about the supported display modes. Either we have the display driver implementing an interface or have an abstract method on a base class.



  • public String getVideoCardManufacturer();
  • public String getVideoCardModel();
  • public int getAmountOfVideoMemory();
  • public DisplayMode[] getSupportedDisplayModes();
  • public DisplayMode getCurrentDisplayMode();
  • public void setDisplayMode(DisplayMode m) throws DisplayModeNotSupportedException;


The DisplayMode interface might have the following methods:


  • public boolean isTextMode();
  • public Dimension getResolution();
  • public int getRefreshRate();
  • public PixelFormat getPixelFormat();
  • public boolean has3DAcceleration();



The above interface begs the question whether there should be two sub-interfaces, TextDisplayMode and GraphicsDisplayMode. Should the graphics driver export the two lists separately? Most graphics cards enter a text display mode by default I think. Some export their own special text display modes.





Coments from Valentin:




My Opinion is that we should pack this informations that the driver can send back into an external class called GraphichDriverInfo and that we should have 2 other interfaces called TextDisplayMode and GraphicsDisplayMode that extend DisplayMode interface. So the list of classes/interfaces(and there methods) should look like this:



  • public interface GraphicDriver;
    • public GraphicDriverInfo getInfo();
  • public class GraphicDriverInfo;
    • public String getVideoCardManufacturer();
    • public String getVideoCardModel();
    • public int getAmountOfVideoMemory();
    • public DisplayMode[] getSupportedDisplayModes();
    • public DisplayMode getCurrentDisplayMode();
    • public void setDisplayMode(DisplayMode m) throws DisplayModeNotSupportedException;
  • public interface DisplayMode;
    • public Dimension getResolution();
    • public int getRefreshRate();
  • public interface TextDisplayMode extends DisplayMode;
    • public boolean isColorTextSupported();
  • public interface GraphicDisplayMode extends DisplayMode;
    • public PixelFormat getPixelFormat();
    • public boolean has3DAcceleration();



Everyone's input on this is wellcomed.

‹ A New Garbage Collection AlgorithmupIsolate proposal ›

This is where JNode can shine

Submitted by rhenry74 on Sat, 11/22/2008 - 01:47.

Code to modern hardware. Mac's decision to use a unix-like core may have failed if they had kept X windows. Microsoft struggles so much with backward compatibility that Vista can actually drop out of accelerated video modes on the fly... how can that be efficient and how can the windowing system be truly optimized?

The windowing system API should be written to hardware that supports overlays first, and consider hardware that has a single frame buffer second. Applications should code to a window supplied by the windowing system. An application should not worry about video modes or video memory. High performance apps. may need access to a frame buffer provided by the windowing system and these apps. may not run in certain modes and that's ok. 32 bit color is available on most modern hardware anyway. You should be able to play a high definition video on a 2Ghz machine with surround sound and have some CPU to spare. Anything less is not fast enough.

To really make a statement this is where JNode can separate itself from the rest of the Java paradigms and give the Java language the performance it has been criticized for not having for so long.

A Basic 3D Cube Example

Submitted by devintraining123 on Sun, 04/13/2008 - 12:58.

May I suggest code such as the following:
void PrintCube [
primitive foo
foo.edges == 12
foo.faces == 6
foo.vertices == 8
foo.color == darkred
foo.rotate == repeat
foo.print
]
to print a rotating dark red cube?

I wont to add to this

Submitted by rusev on Thu, 07/13/2006 - 18:49.

I wont to add to this discussion some modern video/media features which are supported with other OS-s (subsystems such as V4L2, DirectFB, DirectX)

>Most graphics cards enter a text display mode by default I think. >Some export their own special text display modes.
That is true if we are speaking about PC architecture, others may even do not have text mode, so that text console must be emulated graphically.

Some graphical devices may have ability to select output mode likes PAL/SECAM/NTSC (but this likely more related to external video devices connected by FireWire, not sure).

Also some parameters related to RGB output are usually controllable such as VSyhc/HSync pulse length and delay, H/V frequencies, interliving and so on.

Some framebuffers may have graphical overlays or even be overlays at other framebuffers themselves, such ones may need additional parameters specifying location over base framebuffer, transparency, Z-order and custom mixing mode

About getPixelFormat() - lkely some infromation about colorplanes
or/and colorlines and byte alignment for pix samples.
There are video capture devices which can benifit from using direct access to video memory due to transfer captured images directly to screen, such devices may need to know all the information above due to select compatible mode.

Some videocards can use orbitary piece of phys RAM as videomemory,
so that they also may send contents of video capture buffer to the screen directly.

I also know devices which have too many videomodes available (which may be difficult to enumerate), and
not all combinations of parameters are available, such as resolution
800x600 may support RGB565 only but 300x200 also support TrueColor,
while 800x600 support YUV color model, but 300x200 don't.

For such cases i think that needed some API likes:
VideoMode setMode(VideoMode newMode)
which tires to set the closest mode and return is or changes
newMode to be correct and set it.
Such approach may help to make video active by default even if we try to set something wrong

At change of parameters some videoadapters' drivers may also need to change video memory addresses, for example if we increase resolutin a driver may need to free videobuffer memory and allocate a new one - bigger.