1
0
Fork 0
Commit graph

8 commits

Author SHA1 Message Date
Neil Roberts
b2e735ff7f Dynamically load the GL or GLES library
The GL or GLES library is now dynamically loaded by the CoglRenderer
so that it can choose between GL, GLES1 and GLES2 at runtime. The
library is loaded by the renderer because it needs to be done before
calling eglInitialize. There is a new environment variable called
COGL_DRIVER to choose between gl, gles1 or gles2.

The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have
been changed so that they don't assume the ifdefs are mutually
exclusive. They haven't been removed entirely so that it's possible to
compile the GLES backends without the the enums from the GL headers.

When using GLX the winsys additionally dynamically loads libGL because
that also contains the GLX API. It can't be linked in directly because
that would probably conflict with the GLES API if the EGL is
selected. When compiling with EGL support the library links directly
to libEGL because it doesn't contain any GL API so it shouldn't have
any conflicts.

When building for WGL or OSX Cogl still directly links against the GL
API so there is a #define in config.h so that Cogl won't try to dlopen
the library.

Cogl-pango previously had a #ifdef to detect when the GL backend is
used so that it can sneakily pass GL_QUADS to
cogl_vertex_buffer_draw. This is now changed so that it queries the
CoglContext for the backend. However to get this to work Cogl now
needs to export the _cogl_context_get_default symbol and cogl-pango
needs some extra -I flags to so that it can include
cogl-context-private.h
2011-07-11 12:57:38 +01:00
Robert Bragg
a1234ee8d1 Add internal _cogl_init() function
This adds a _cogl_init function for Cogl that we expect to be the first
thing called before anything else is done with Cogl. It's not a public
API so it's expected that all entry points for Cogl that might be the
first function used should call _cogl_init().

We currently call _cogl_init() in these functions:
  cogl_renderer_new
  cogl_display_new
  cogl_context_new
  cogl_android_set_native_window

_cogl_init() can be called multiple times, and only the first call has
any affect.

For example _cogl_init() gives us a place check and parse the COGL_DEBUG
environment variable.

Since we don't have any need to parse command line arguments (we can
always get user configuration options from the environment) our init
function doesn't require argc/argv pointers.

By saying up front that we aren't interested in command line arguments
that means we can avoid the mess that is GOption based library
initialization which is extremely fragile due to its lack of dependency
tracking between modules.

Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-30 14:33:11 +01:00
Robert Bragg
a29a76dbab Adds _cogl_wayland_texture_2d_new_from_buffer API
This adds internal API to be able to wrap a wayland buffer as a
CoglTexture2D. There is a --enable-wayland-egl-server option to decide
if Cogl should support this feature and potentially any EGL based winsys
could support this through the EGL_KHR_image_base and
EGL_WL_bind_display extensions.
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
Robert Bragg
7037812ae6 EGL: Updates GDL platform support
The GDL API is used for example on intel ce4100 (aka Sodaville) based
systems as a way to allocate memory that can be composited using the
platforms overlay hardware. This updates the Cogl EGL winsys and the
support in Clutter so we can continue to support these platforms.
2011-05-05 14:46:02 +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
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