Commit Graph

58 Commits

Author SHA1 Message Date
Robert Bragg
60b25615fd Add _cogl_egl_texture_2d_new_from_image API
This adds an internal texture_2d constructor that can wrap an EGLImage
as a CoglTexture2D. The plan is to utilize this for texture-from-pixmap
support with EGL as well as creating textures from wayland buffers.
2011-06-01 20:44:42 +01:00
Robert Bragg
b380fed23d Make stub winsys into a proper winsys backend
Instead of the stub winsys being a special case set of #ifdef'd code
used when COGL_HAS_FULL_WINSYS wasn't defined, the stub winsys now
implements a CoglWinsysVtable like all other winsys backends (it's just
that everything is a NOP). This way we can get rid of the
COGL_HAS_FULL_WINSYS define and also the stub winsys can be runtime
selected whereas before it was incompatible with all other winsys
backends.
2011-06-01 20:44:41 +01:00
Neil Roberts
6788c80342 Add a WGL winsys
This adds a full winsys to handle WGL and Win32.
2011-05-10 17:58:41 +01:00
Robert Bragg
31ee65784d winsys: Expose environment variable to choose winsys
This makes it possible to override the winsys that cogl uses by setting
the COGL_RENDERER environment variable e.g. to "GLX" or "EGL"
2011-05-05 14:46:01 +01:00
Robert Bragg
dc7383b714 Add a vtable of indirection to the winsys code
So that we can dynamically select what winsys backend to use at runtime
we need to have some indirection to how code accesses the winsys instead
of simply calling _cogl_winsys* functions that would collide if we
wanted to compile more than one backend into Cogl.
2011-05-05 14:46:01 +01:00
Neil Roberts
f6ae9decaa cogl-renderer: Move the XEvent filters to be generic for all renderers
Instead of having cogl_renderer_xlib_add_filter and friends there is
now cogl_renderer_add_native_filter which can be used regardless of
the backend. The callback function for the filter now just takes a
void pointer instead of an XEvent pointer which should be interpreted
differently depending on the backend. For example, on Xlib it would
still be an XEvent but on Windows it could be a MSG. This simplifies
the code somewhat because the _cogl_xlib_add_filter no longer needs to
have its own filter list when a stub renderer is used because there is
always a renderer available.

cogl_renderer_xlib_handle_event has also been renamed to
cogl_renderer_handle_native_event. This just forwards the event on to
all of the listeners. The backend renderer is expected to register its
own event filter if it wants to process the events in some way.
2011-04-20 18:17:06 +01:00
Robert Bragg
d40cdfa3e1 Moves all GLX code down from Clutter to Cogl
This migrates all the GLX window system code down from the Clutter
backend code into a Cogl winsys. Moving OpenGL window system binding
code down from Clutter into Cogl is the biggest blocker to having Cogl
become a standalone 3D graphics library, so this is an important step in
that direction.
2011-04-11 17:54:36 +01:00
Robert Bragg
bcd97f35ea Adds renderer,display,onscreen-template and swap-chain stubs
As part of the process of splitting Cogl out as a standalone graphics
API we need to introduce some API concepts that will allow us to
initialize a new CoglContext when Clutter isn't there to handle that for
us...

The new objects roughly in the order that they are (optionally) involved
in constructing a context are: CoglRenderer, CoglOnscreenTemplate,
CoglSwapChain and CoglDisplay.

Conceptually a CoglRenderer represents a means for rendering.  Cogl
supports rendering via OpenGL or OpenGL ES 1/2.0 and those APIs are
accessed through a number of different windowing APIs such as GLX, EGL,
SDL or WGL and more. Potentially in the future Cogl could render using
D3D or even by using libdrm and directly banging the hardware. All these
choices are wrapped up in the configuration of a CoglRenderer.

Conceptually a CoglDisplay represents a display pipeline for a renderer.
Although Cogl doesn't aim to provide a detailed abstraction of display
hardware, on some platforms we can give control over multiple display
planes (On TV platforms for instance video content may be on one plane
and 3D would be on another so a CoglDisplay lets you select the plane
up-front.)

Another aspect of CoglDisplay is that it lets us negotiate a display
pipeline that best supports the type of CoglOnscreen framebuffers we are
planning to create. For instance if you want transparent CoglOnscreen
framebuffers then we have to be sure the display pipeline wont discard
the alpha component of your framebuffers. Or if you want to use
double/tripple buffering that requires support from the display
pipeline.

CoglOnscreenTemplate and CoglSwapChain are how we describe our default
CoglOnscreen framebuffer configuration which can affect the
configuration of the display pipeline.

The default/simple way we expect most CoglContexts to be constructed
will be via something like:

 if (!cogl_context_new (NULL, &error))
   g_error ("Failed to construct a CoglContext: %s", error->message);

Where that NULL is for an optional "display" parameter and NULL says to
Cogl "please just try to do something sensible".

If you want some more control though you can manually construct a
CoglDisplay something like:

 display = cogl_display_new (NULL, NULL);
 cogl_gdl_display_set_plane (display, plane);
 if (!cogl_display_setup (display, &error))
   g_error ("Failed to setup a CoglDisplay: %s", error->message);

And in a similar fashion to cogl_context_new() you can optionally pass
a NULL "renderer" and/or a NULL "onscreen template" so Cogl will try to
just do something sensible.

If you need to change the CoglOnscreen defaults you can provide a
template something like:
  chain = cogl_swap_chain_new ();
  cogl_swap_chain_set_has_alpha (chain, TRUE);
  cogl_swap_chain_set_length (chain, 3);

  onscreen_template = cogl_onscreen_template_new (chain);
  cogl_onscreen_template_set_pixel_format (onscreen_template,
                                           COGL_PIXEL_FORMAT_RGB565);

  display = cogl_display_new (NULL, onscreen_template);
  if (!cogl_display_setup (display, &error))
    g_error ("Failed to setup a CoglDisplay: %s", error->message);
2011-04-11 17:54:35 +01:00