This adds a version header which contains macros to define which
version of Cogl the application is being compiled against. This helps
applications that want to support multiple incompatible versions of
Cogl at compile time.
The macros are called COGL_VERSION_{MAJOR,MINOR,MICRO}. This does not
match Clutter which names them CLUTTER_{MAJOR,MINOR,MICRO}_VERSION but
I think the former is nicer and it at least matches Cairo and Pango.
The values of the macro are defined to COGL_VERSION_*_INTERNAL which
is generated by the configure script into cogl-defines.h.
There is also a macro for the entire version as a string called
COGL_VERSION_STRING.
The internal utility macros for encoding a 3 part version number into
a single integer have been moved into the new header so they can be
used publicly as a convenient way to check if the version is within a
particular range. There is also a COGL_VERSION_CHECK macro for the
very common case that a feature will be used since a particular
version of Cogl. There is a macro called COGL_VERSION which contains
the pre-encoded version of Cogl being compiled against for
convenience.
Unlike in Clutter this patch does not add any runtime version
identification mechanism.
A test case is also added which just contains static asserts to sanity
check the macros.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
(cherry picked from commit 3480cf140dc355fa87ab3fbcf0aeeb0124798a8f)
The coding style has for a long time said to avoid using redundant glib
data types such as gint or gchar etc because we feel that they make the
code look unnecessarily foreign to developers coming from outside of the
Gnome developer community.
Note: When we tried to find the historical rationale for the types we
just found that they were apparently only added for consistent syntax
highlighting which didn't seem that compelling.
Up until now we have been continuing to use some of the platform
specific type such as gint{8,16,32,64} and gsize but this patch switches
us over to using the standard c99 equivalents instead so we can further
ensure that our code looks familiar to the widest range of C developers
who might potentially contribute to Cogl.
So instead of using the gint{8,16,32,64} and guint{8,16,32,64} types this
switches all Cogl code to instead use the int{8,16,32,64}_t and
uint{8,16,32,64}_t c99 types instead.
Instead of gsize we now use size_t
For now we are not going to use the c99 _Bool type and instead we have
introduced a new CoglBool type to use instead of gboolean.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 5967dad2400d32ca6319cef6cb572e81bf2c15f0)
Mesa before version 8.0.2 has a slow read pixels path that gets used
with the Intel driver where it converts all of the pixels into a
floating point representation and back even if the data is being read
into exactly the same format. There is however a faster path using the
blitter when reading into a PBO with BGRA format. It works out faster
to read into a PBO and then memcpy back out into the application's
buffer even though it adds an extra memcpy. This patch adds a
workaround in cogl_framebuffer_read_pixels_into_bitmap when it detects
this situation. In that case it will create a temporary CoglBitmap
using cogl_bitmap_new_with_size, read into it and then memcpy the data
back out.
The main impetus for this patch is that Gnome Shell has implemented
this workaround directly using GL calls but it seems like the kind of
thing that would sit better at the Cogl layer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a CoglGpuInfo struct to the CoglContext which contains some
enums describing the GL driver in use. This currently includes the
driver package (ie, is it Mesa) the version number of the package and
the vendor of the GPU (ie, is it by Intel). There is also a bitmask
which will contain the workarounds that we should do for that
particular driver configuration. The struct is initialised on context
creation by using a series of string comparisons on the strings
returned from glGetString.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
