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 ›

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.