1
0
Fork 0
Commit graph

6 commits

Author SHA1 Message Date
Damien Lespiau
56dd71dba0 cogl: Introduce private feature flags and check for ARB_fp
The Cogl context has now a feature_flags_private enum that will allow us
to query and use OpenGL features without exposing them in the public
API.

The ARB_fragment_program extension is the first user of those flags.
Looking for this extension only happens in the gl driver as the gles
drivers will not expose them.

One can use _cogl_features_available_private() to check for the
availability of such private features.

While at it, reindent cogl-internal.h as described in CODING_STYLE.
2010-06-09 15:19:30 +01:00
Emmanuele Bassi
72f4ddf532 Remove mentions of the FSF address
Since using addresses that might change is something that finally
the FSF acknowledge as a plausible scenario (after changing address
twice), the license blurb in the source files should use the URI
for getting the license in case the library did not come with it.

Not that URIs cannot possibly change, but at least it's easier to
set up a redirection at the same place.

As a side note: this commit closes the oldes bug in Clutter's bug
report tool.

http://bugzilla.openedhand.com/show_bug.cgi?id=521
2010-03-01 12:56:10 +00:00
Damien Lespiau
ca80e8802b cogl-pixel-buffer: Add a fallback path
First, let's add a new public feature called, surprisingly,
COGL_FEATURE_PBOS to check the availability of PBOs and provide a
fallback path when running on older GL implementations or on OpenGL ES

In case the underlying OpenGL implementation does not provide PBOs, we
need a fallback path (a malloc'ed buffer). The CoglPixelBufer
constructors will instanciate a subclass of CoglBuffer that handles
map/unmap and set_data() with a malloc'ed buffer.

The public feature is useful to check before using set_data() on a
buffer as it will mean doing a memcpy() when not supporting PBOs (in
that case, it's better to create the texture directly instead of using a
CoglBuffer).
2010-02-08 17:14:49 +00:00
Neil Roberts
0927f35e7a cogl: Use the GL_EXT_blend_{func,equation}_separate extensions
We should use these extensions to check for glBlendFuncSeparate and
glBlendEquationSeparate as well as checking the GL version number.
2009-11-17 18:06:31 +00:00
Neil Roberts
2a53b84d18 cogl: Don't bother checking for NPOTs or VBOs on later GLs
For VBOs, we don't need to check for the extension if the GL version
is greater than 1.5. Non-power-of-two textures are given in 2.0.

We could also assume shader support in GL 2.0 except that the function
names are different from those in the extension so it wouldn't work
well with the current mechanism.
2009-11-17 17:22:22 +00:00
Neil Roberts
058d79dce2 cogl: Make it easier to add checks for GL extensions
Previously if you need to depend on a new GL feature you had to:

- Add typedefs for all of the functions in cogl-defines.h.in

- Add function pointers for each of the functions in
  cogl-context-driver.h

- Add an initializer for the function pointers in
  cogl-context-driver.c

- Add a check for the extension and all of the functions in
  cogl_features_init. If the extension is available under multiple
  names then you have to duplicate the checks.

This is quite tedious and error prone. This patch moves all of the
features and their functions into a list of macro invocations in
cogl-feature-functions.h. The macros can be redefined to implement all
of the above tasks from the same header.

The features are described in a struct with a pointer to a table of
functions. A new function takes the feature description from this
struct and checks for its availability. The feature can take a list of
extension names with a list of alternate namespaces (such as "EXT" or
"ARB"). It can also detect the feature from a particular version of
GL.

The typedefs are now gone and instead the function pointer in the Cogl
context just directly contains the type.

Some of the functions in the context were previously declared with the
'ARB' extension. This has been removed so that now all the functions
have no suffix. This makes more sense when the extension could
potentially be merged into GL core as well.
2009-11-17 15:11:26 +00:00