Since this API references CoglOutput, but occurs in a
non-experimental header, we need to guard it so that an include
of cogl.h without -DCOGL_ENABLE_EXPERIMENTAL_API doesn't beak.

Consistently use Since: 1.14 Stability: Unstable for CoglFrameInfo
related additions, also guard cogl-output.h and cogl-frame-info.h
with COGL_ENABLE_EXPERIMENTAL_API.

Instead of converting gettimeofday() UST values into
clock_gettime(CLOCK_MONOTONIC, ...), just return them raw, and the
caller can convert using cogl_clock_get_time().

Add an API to get the current time in the time system that Cogl
is reporting timestamps. This is to be used to convert timestamps
into a different time system.

An application gets a callback when a frame info is complete, so there
may not be a need for a flag as well.

An arbitrary-length frame history seems hard to size, and can be implemented
at the application level, so ditch it for a queue of frame info objects
that are not yet complete.

In the future, we may want to track frame timings with very high precision
for profiling purposes, so to be consistent with that, use nanoseconds,
not microseconds. 63-bits in nanoseconds is 270+ years, so hopefully
clock_gettime(CLOCK_MONOTONIC,) will fit.

Avoid a hard dependency on GLib and on however GLib is implementing
g_get_monotonic_time() by directly referencing clock_gettime(CLOCK_MONOTONIC).

The translation of timestamp values for unidentified types of UST is
also removed, since it's going to have a big error, and
glXGetSyncValues() doesn't return the *current* UST anyways - it returns
the UST for the last frame.

The frame_time isn't closely associated with an onscreen - an update
could involve multiple stages (in a stage-per-output scenario, perhaps.)
If an application or toolkit needs to know the frame time for a FrameInfo
it will have to do that association itself.

If available from the windowing system, it could potentially be useful
to know something other than the refresh rate of the output that the
monitor is currently presenting on. (Note however, an onscreen may span
multiple outputs. The windowing system has to pick *one* for timing,
but most other attibutes of the window will apply to the parts of the
onscreen on that output.)

This reworks the cogl_onscreen_add_swap_complete_callback api to instead
be named cogl_onscreen_add_frame_callback and to take a callback that
can accept other events besides just swap completion events. This means
we can add more events in the future that signal the progression of a
frame without needing lots of new callback api for each event.

TODO: squash this back into owen's patch

This adds a cogl_renderer_foreach_output() function that can be used to
iterate the display outputs for a particular renderer.

This also updates cogl-info to use this new api so it can dump out all
the output information.

For consistency this reworks the cogl_frame_info_get_refresh_interval
api to instead be cogl_frame_info_get_refresh_rate() and return a
frequency in Hertz instead of an interval in milliseconds. This is
consistent with cogl_output_get_refresh_rate().

As discussed on the mailing list we can be slightly more consistent with gtk
by using "frame" instead of "swap" here. Also we discussed the potential
for being able to query information for a frame that's still in progress
and in that case "swap" wouldn't make much sense.

TODO: squash this back into owen's patch

TODO: squash back into owen's patch

The aim is to pass an opaque structure to the swap buffers notification
callbacks and enable access to frame timing information this way. Since
there could be numerous non-timing related things to report here too
this gives the structure a more general name.

TODO: fold this back into owen's patch

TODO: squash back into owen's patch

TODO: squash back into owen's patch

TODO: squash back into owen's patch

Add a CoglFrameTimings object that tracks timing information
for frames that are drawn. We track a frame counter and frame
timing information for each CoglOnscreen. Frames timing information
is deliminated by a new cogl_onscreen_begin_frame() and retrieved using
cogl_onscreen_get_frame_timings().

When we block waiting for the swap, prefer doing that using
glXWaitForMsc() from OML_sync_control because that returns a system
time value for the precise time of the swap.

Should have been part of "Add CoglOutput and track for the GLX backend"

The CoglOutput object represents one output such as a monitor or
laptop panel, with information about attributes of the output such as
the position of the output within the global coordinate space, and
the refresh rate.

We don't yet publically export the ability to get output information but
we track it for the GLX backend, where we'll use it to track the refresh
rate.

https://bugzilla.gnome.org/show_bug.cgi?id=691944



Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit 397e6734)

The rounding used when storing 10-bit per component data into an 8-bit
per component texture seems to have changed in recent versions of Mesa
which was causing this test to fail. I've also noticed this failing on
the NVidia binary driver. This patch adds some fuzziness to the
comparison so that it will pass. There is a new test_utils function
called test_utils_compare_pixel_and_alpha which is the same as
test_utils_compare_pixel except that it also compares the alpha
component.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit ce626fb3)

It looks like it's not meant to be valid to create a framebuffer with
an alpha-only texture as a render target on GLES. Since the following
Mesa commit, this requirement is now enforced so that the
test_framebuffer_get_bits test fails:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=cf300eaa



Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit cfb0859c)

Previously the functions for packing and unpacking pixels where
generated by token pasting together a function name along with its
type, like the following:

 _cogl_pack_ ## uint8_t

Then later in cogl-bitmap-conversion.c it would directly refer to the
function names without token pasting.

This wouldn't work however if the system headers define the stdint
types using #defines instead of typedefs because in that case the
function name generated using token pasting would get the expanded
type name but the reference that doesn't use token pasting wouldn't.

This patch adds an extra macro passed to the cogl-bitmap-packing.h
header which just has the type size. That way the function can be
defined like this instead:

 _cogl_pack_ ## 8

That should prevent it from hitting problems with #defined types.

https://bugzilla.gnome.org/show_bug.cgi?id=691945



Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit d6b5d708)

This make autogen.sh look for automake-1.13 and also updates all
Makefile.am files to no longer use the INCLUDES variable which automake
1.13 warns is deprecated by AM_CPPFLAGS.

https://bugzilla.gnome.org/show_bug.cgi?id=690891



Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit 5de5569e)

This marks that test-backface-culling is currently known to fail without
NPOT texture support. This allows us do a 1.13 snapshot release before
we find a fix for this.

We have a workaround in Cogl to fix viewport clipping with Mesa Intel
Gen 6 drivers but this was breaking the semantics of
cogl_framebuffer_clear() which should not be affected by viewport
clipping. This makes sure we disable and restore the workaround when
clearing the framebuffer. This fixes Clutter's test-cogl-viewport
conformance test.

This tweaks the ordering of some struct members in some of the more
important structs so that the compiler won't insert wasted padding to
avoid breaking the alignment. Some members that were previously
unsigned long have been changed to unsigned int. These members need to
be able to fit in 32-bits to run on 32-bit machines anyway so there's
no point in having them extend to 64-bit on 64-bit machines. This
doesn't affect the public API.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit b721af23)

In commit 1fa7c0f1

 the sliced texture code which creates the
array of pointers to the texture slices was changed so that the
textures are appended to the end of the array instead of initially
creating the array with the right size upfront and then shrinking the
array on error. However it was then still also setting the size of the
array after creating it so the new textures would actually end up in
an unused part of the array. The part of the array that is used was
left unitialised so it would crash. This just removes the call to set
the size of the array.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 7df09d50)

GL3 has support for clip planes but they are used differently and
involve writing to a builtin output variable in the vertex shader. The
current clip plane code assumes it is only used with a fixed function
driver and tries to directly push to the matrix builtins. This
obviously won't work on GL3 so for now let's just disable clip planes.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 5f621589)

When a component-alpha texture is made using a GL3 context a GL_RED
texture is actually used and a swizzle is set up to hide it. However
if a framebuffer is then bound to that texture then when the bits are
queried this workaround will leak out of the API. To fix this it now
detects the situation and reports the number of red bits as the number
of alpha bits.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 425cfb26)

Previously when the context was initialised Cogl would query the
number of stencil bits and set a private feature flag to mark that it
can use the buffer for clipping if there was at least 3. The problem
with this is that the number of stencil bits returned by
GL_STENCIL_BITS depends on the currently bound framebuffer. This patch
adds an internal function to query the number of stencil bits in a
framebuffer and makes it use that instead when determining whether it
can push the clip using the stencil buffer.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit e928d215)