To help us handle sliced textures; When flushing materials there is an
override option that can be given to replace the texture name for layer0
so we may iterate the slices without needing to modify the material
in use.
Since improving the journal's ability to batch state changes we added a
_cogl_material_equals function that is used by the journal to compare
materials and identify when a state change is required, but this wasn't
correctly considering the layer0 override resulting in false positives that
meant the journal wouldn't update the GL state and the first texture name
was used for all slices.
To help us handle sliced textures; When flushing materials there is an
override option that can be given to replace the texture name for layer0
so we may iterate the slices without needing to modify the material
in use.
Since improving the journal's ability to batch state changes we added a
_cogl_material_equals function that is used by the journal to compare
materials and identify when a state change is required, but this wasn't
correctly considering the layer0 override resulting in false positives that
meant the journal wouldn't update the GL state and the first texture name
was used for all slices.
The cost of glGetFloatv with Mesa is still representing a majority of our
time in OpenGL for some applications, and the last thing left using this is
the current-matrix API when getting the projection matrix.
This adds a matrix stack for the projection matrix, so all getting, setting
and modification of the projection matrix is now managed by Cogl and it's only
when we come to draw that we flush changes to the matrix to OpenGL.
This also brings us closer to being able to drop internal use of the
deprecated OpenGL matrix functions, re: commit 54159f5a1d02
The cost of glGetFloatv with Mesa is still representing a majority of our
time in OpenGL for some applications, and the last thing left using this is
the current-matrix API when getting the projection matrix.
This adds a matrix stack for the projection matrix, so all getting, setting
and modification of the projection matrix is now managed by Cogl and it's only
when we come to draw that we flush changes to the matrix to OpenGL.
This also brings us closer to being able to drop internal use of the
deprecated OpenGL matrix functions, re: commit 54159f5a1d02
If we are starting on something other than the first workspace,
meta_compositor_switch_workspace() will be called before
meta_compositor_manage_screen(); guard against that.
Previously, changes to the visibility of a window could be indicated
by meta_compositor_map_window(), meta_compositor_unminimize_window(),
meta_compositor_set_window_hidden(), etc, with the exact behavior
depending on the 'live_hidden_windows' preference.
Simplify this so that visibility is controlled by:
meta_compositor_show_window()
meta_compositor_hide_window()
With an 'effect' parameter provided to indicate the appropriate
effect (CREATE/UNMINIMIZE/MINIMIZE/DESTROY/NONE.)
The map state of the window is signalled separately by:
meta_compositor_map_window()
meta_compositor_unmap_window()
And is used only to control resource handling.
Other changes:
* The desired effect on show/hide is explicitly stored in
MetaWindow, avoiding the need for the was_minimized flag.
At idle, once we calculate the window state, we pass the
effect to the compositor if it matches the new window
state, and then clear the effect to start over for future
map state changes.
* meta_compositor_switch_workspace() is called before any windows
are hidden or shown, allowing the compositor to avoid hiding
or showing an effect for windows involved in the switch.
http://bugzilla.gnome.org/show_bug.cgi?id=582341
* Handling of post-effect cleanups for MutterWindow are
simplified - instead of trying to do different things based
on the individual needs of different effects, we just wait until
all effects complete and sync the window state to what it
should be.
* On unmap, once we destroy the pixmap, we tell ClutterX11Pixmap
that we've done so, so it can clean up and unbind. (The
unbinding doesn't seem to be working properly because of
ClutterGLXPixmap or video driver issues.)
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Clean up mutter_window_effect_in_progress() by removing the
include_destroy parameter which was used only in one place that
could be easily done otherwise. (There was another use in
mutter_window_sync_actor_position() that had no point and looked
unintended.)
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Add a paint function that checks all windows for repair and
shape updates; this:
- simplifies the logic for when a window needs to be repaired
- avoids duplicate work when we get multiple damage effects
- avoids the need to look ahead in the event queue
Instead of relying on repair to implicitly resize the
MutterWindow actor, set the size explicitly when the core
code updates the geometry. (This is needed because we haven't
repaired yet when we start an animation, and the animation
may depend on the size to, e.g., rescale from the center.)
Because the core geometry update happens before we start
maximize/unmaximize effects we need to work around this by
passing both the old and new geometry to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Putting hidden windows in the desktop layer is pointless - in
the desktop layer isn't necessary below all visible windows,
and we are hiding the windows by other means. And the movement
isn't reliable because nothing sets stack->needs_relayer, so
windows can get stuck in the desktop layer after being
rehidden.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
compositor.c: Move MutterWindow code to mutter-window.c;
rename map_win() to mutter_window_map(), etc.
mutter-window-private.h: New private header file for
MutterWindow functions used internally to the compositor.
compositor-mutter.h: Move MutterWindow declarations to
mutter-window.h; move a couple of private functions to
compositor-private.h
compositor-private.h: Move MetaCompScreen declaration to here:
Conceptually it's private to compositor.c, but MutterWindow
manipulates some of the lists directly for now.
mutter-plugin.c compositor.c: Don't call mutter_window_effect_completed()
for MUTTER_PLUGIN_SWITCH_WORKSPACE, but use a new
mutter_switch_workspace_completed(), since the window is
just used to identify a screen.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
Separate code related to creating the gaussian-blurred shadow texture
into a separate file.
Move the definition of MetaCompositor into a compositor-private.h
so that the shadow code can cache the source in the compositor
structure.
http://bugzilla.gnome.org/show_bug.cgi?id=587251
The patch adds GLib marshalling code to Mutter, since it's required for the "workspace-switched" signal.
The definition of MetaMotionDirection enum is moved to common.h since it's now used in workspace.c.
A little cleaning is done in workspace.c:meta_workspace_activate_with_focus(), where compositor-specific code is merged with the rest of the function (required to emit signal), removing #ifdefs.
Scanners like gtk-doc and g-ir-scanner get confused by:
typedef struct _Foo {
...
} Foo;
And expect instead:
typedef struct _Foo Foo;
struct _Foo {
...
};
CoglMatrix definition should be changed to avoid the former type.
The clutter_actor_get_allocation_coords() is not used, and since
the switch to floats in the Actor's API, it returns exactly what
the get_allocation_box() returns.
Currently, the transformation matrix for an actor is constructed
from scenegraph-related accessors. An actor, though, can call COGL
API to add new transformations inside the paint() implementation,
for instance:
static void
my_foo_paint (ClutterActor *a)
{
...
cogl_translate (-scroll_x, -scroll_y, 0);
...
}
Unfortunately these transformations will be completely ignored by
the scenegraph machinery; for instance, getting the actor-relative
coordinates from event coordinates is going to break badly because
of this.
In order to make the scenegraph aware of the potential of additional
transformations, we need a ::apply_transform() virtual function. This
vfunc will pass a CoglMatrix which can be used to apply additional
operations:
static void
my_foo_apply_transform (ClutterActor *a, CoglMatrix *m)
{
CLUTTER_ACTOR_CLASS (my_foo_parent_class)->apply_transform (a, m);
...
cogl_matrix_translate (m, -scroll_x, -scroll_y, 0);
...
}
The ::paint() implementation will be called with the actor already
using the newly applied transformation matrix, as expected:
static void
my_foo_paint (ClutterActor *a)
{
...
}
The ::apply_transform() implementations *must* chain up, so that the
various transformations of each class are preserved. The default
implementation inside ClutterActor applies all the transformations
defined by the scenegraph-related accessors.
Actors performing transformations inside the paint() function will
continue to work as previously.
Scanners like gtk-doc and g-ir-scanner get confused by:
typedef struct _Foo {
...
} Foo;
And expect instead:
typedef struct _Foo Foo;
struct _Foo {
...
};
CoglMatrix definition should be changed to avoid the former type.
The race we were experiencing in the X11 backends is apparently
back after the fix in commit 00a3c698.
This time, just delaying the setting of the SYNC_MATRICES flag
is not enough, so we can resume the use of a STAGE_IN_RESIZE
private flag.
This should also fix bug:
http://bugzilla.openedhand.com/show_bug.cgi?id=1668
In order to validate the sequence of:
XResizeWindow
ConfigureNotify
glViewport
that should happen on X11 we need to add debug annotations to the
calls to glViewport() done through COGL.
In order to validate the sequence of:
XResizeWindow
ConfigureNotify
glViewport
that should happen on X11 we need to add debug annotations to the
calls to glViewport() done through COGL.
This avoids some calls to glGetFloatv, which have at least proven to be very
in-efficient in mesa at this point in time, since it always updates all derived
state even when it may not relate to the state being requested.
This avoids some calls to glGetFloatv, which have at least proven to be very
in-efficient in mesa at this point in time, since it always updates all derived
state even when it may not relate to the state being requested.
Fixes and adds a unit test for creating and drawing using materials with
COGL_INVALID_HANDLE texture layers.
This may be valid if for example the user has set a texture combine string
that only references a constant color.
_cogl_material_flush_layers_gl_state will bind the fallback texture for any
COGL_INVALID_HANDLE layer, later though we could explicitly check when the
current blend mode does't actually reference a texture source in which case
binding the fallback texture is redundant.
This tests drawing using cogl_rectangle, cogl_polygon and
cogl_vertex_buffer_draw.
Fixes and adds a unit test for creating and drawing using materials with
COGL_INVALID_HANDLE texture layers.
This may be valid if for example the user has set a texture combine string
that only references a constant color.
_cogl_material_flush_layers_gl_state will bind the fallback texture for any
COGL_INVALID_HANDLE layer, later though we could explicitly check when the
current blend mode does't actually reference a texture source in which case
binding the fallback texture is redundant.
This tests drawing using cogl_rectangle, cogl_polygon and
cogl_vertex_buffer_draw.
[cogl] Improve ability to break out into raw OpenGL via begin/end mechanism
Adds a cogl_flush() to give developers breaking into raw GL a fighting chance
[cogl-material] Be more carefull about flushing in cogl_material_remove_layer
Revert "[rectangle] Avoid modifying materials mid scene"
Revert "[actor] Avoid modifying materials mid-scene to improve journal batching"
[cogl-vertex-buffer] Disable unused client tex coord arrays
[cogl] disable all client tex coord arrays in _cogl_add_path_to_stencil_buffer
[cogl] flush matrices in _cogl_add_path_to_stencil_buffer
[journal] Don't resize a singlton VBO; create and destroy a VBO each flush
[cogl] avoid using the journal in _cogl_add_path_to_stencil_buffer
[pango-display-list] Use the Cogl journal for short runs of text
[material] _cogl_material_equal: catch the simplest case of matching handles
[material] avoid flushing the journal when just changing the color
[cogl journal] Perform software modelview transform on logged quads.
[Cogl journal] use G_UNLIKLEY around runtime debugging conditions
[cogl journal] Adds a --cogl-debug=batching option to trace batching
[Cogl journal] Adds a --cogl-debug=journal option for tracing the journal
[cogl] Adds a debug option for disabling use of VBOs --cogl-debug=disable-vbos
[cogl] Force Cogl to always use the client side matrix stack
[cogl-debug] Adds a "client-side-matrices" Cogl debug option
[cogl-color] Adds a cogl_color_equal() function
[cogl material] optimize logging of material colors in the journal
[rectangle] Avoid modifying materials mid scene
[actor] Avoid modifying materials mid-scene to improve journal batching
[journal] Always pad our vertex data as if at least 2 layers are enabled
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
The Cogl journal is a mechanism Cogl uses to batch geometry resulting from
any of the cogl_rectangle* functions before sending it to OpenGL. This aims
to improve the Cogl journal so that it can reduce the number of state
changes and draw calls we issue to the OpenGL driver and hopfully improve
performance.
Previously each call to any of the cogl_rectangle* functions would imply an
immediate GL draw call, as well as a corresponding modelview change;
material state changes and gl{Vertex,Color,TexCoord}Pointer calls. Now
though we have tried to open the scope for batching up as much as possible
so we only have to flush the geometry either before calling glXSwapBuffers,
or when we change state that isn't tracked by the journal.
As a basic example, it's now possible for us to batch typical picking
renders into a single draw call for the whole scene.
Some key points about this change:
- We now perform transformations of quads in software (except for long runs of
text which continue to use VBOs)
* It might seem surprising at first, but when you consider that so many
Clutter actors are little more than textured quads and each actor
typically implies a modelview matrix change; the costs involved in
setting up the GPU with the new modelview can easily out weigh the cost
of simply transforming 4 vertices.
- We always use Cogl's own client side matrix API now.
* We found the performance of querying the OpenGL driver for matrix state
was often worse than using the client matrix code, and also - discussing
with Mesa developers - agreed that since khronos has essentially
deprecated the GL matrix API (by removing it from OpenGL 3 and
OpenGL-ES 2) it was appropriate to take full responsibility for all our
matrix manipulation.
- Developers should avoid modifying materials mid-scene.
* With the exception of material color changes, if you try and modify a
material that is referenced in the journal we will currently force a
journal flush. Note: you can assume that re-setting the same value for
a material property won't require a flush though.
- Several new --cogl-debug options have been added
* "disable-batching" can be used to identify bugs in the way that the
journal does its batching; of could this shouldn't ever be needed :-)
* "disable-vbos" can be used to test the VBO fallback paths where we
simply use malloc()'d buffers instead.
* "batching" lets you get an overview of how the journal is batching
your geometry and may help you identify ways to improve your
application performance.
* "journal" lets you trace all the geometry as it gets logged in the
journal, and all the geometry as its flushed from the journal.
Obviously an inconsistency can identify a bug, but the numbers may
help you verify application logic too.
* "disable-software-transform" as implied will instead use the driver
/GPU to transform quads by the modelview matrix.
Although committed separately a --clutter-debug=nop-picking option was
also added that lets you remove picking from the equation, which can
sometimes help make problem analysis more deterministic.
[cogl] Improve ability to break out into raw OpenGL via begin/end mechanism
Adds a cogl_flush() to give developers breaking into raw GL a fighting chance
[cogl-material] Be more carefull about flushing in cogl_material_remove_layer
Revert "[rectangle] Avoid modifying materials mid scene"
Revert "[actor] Avoid modifying materials mid-scene to improve journal batching"
[cogl-vertex-buffer] Disable unused client tex coord arrays
[cogl] disable all client tex coord arrays in _cogl_add_path_to_stencil_buffer
[cogl] flush matrices in _cogl_add_path_to_stencil_buffer
[journal] Don't resize a singlton VBO; create and destroy a VBO each flush
[cogl] avoid using the journal in _cogl_add_path_to_stencil_buffer
[pango-display-list] Use the Cogl journal for short runs of text
[material] _cogl_material_equal: catch the simplest case of matching handles
[material] avoid flushing the journal when just changing the color
[cogl journal] Perform software modelview transform on logged quads.
[Cogl journal] use G_UNLIKLEY around runtime debugging conditions
[cogl journal] Adds a --cogl-debug=batching option to trace batching
[Cogl journal] Adds a --cogl-debug=journal option for tracing the journal
[cogl] Adds a debug option for disabling use of VBOs --cogl-debug=disable-vbos
[cogl] Force Cogl to always use the client side matrix stack
[cogl-debug] Adds a "client-side-matrices" Cogl debug option
[cogl-color] Adds a cogl_color_equal() function
[cogl material] optimize logging of material colors in the journal
[rectangle] Avoid modifying materials mid scene
[actor] Avoid modifying materials mid-scene to improve journal batching
[journal] Always pad our vertex data as if at least 2 layers are enabled
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
The Cogl journal is a mechanism Cogl uses to batch geometry resulting from
any of the cogl_rectangle* functions before sending it to OpenGL. This aims
to improve the Cogl journal so that it can reduce the number of state
changes and draw calls we issue to the OpenGL driver and hopfully improve
performance.
Previously each call to any of the cogl_rectangle* functions would imply an
immediate GL draw call, as well as a corresponding modelview change;
material state changes and gl{Vertex,Color,TexCoord}Pointer calls. Now
though we have tried to open the scope for batching up as much as possible
so we only have to flush the geometry either before calling glXSwapBuffers,
or when we change state that isn't tracked by the journal.
As a basic example, it's now possible for us to batch typical picking
renders into a single draw call for the whole scene.
Some key points about this change:
- We now perform transformations of quads in software (except for long runs of
text which continue to use VBOs)
* It might seem surprising at first, but when you consider that so many
Clutter actors are little more than textured quads and each actor
typically implies a modelview matrix change; the costs involved in
setting up the GPU with the new modelview can easily out weigh the cost
of simply transforming 4 vertices.
- We always use Cogl's own client side matrix API now.
* We found the performance of querying the OpenGL driver for matrix state
was often worse than using the client matrix code, and also - discussing
with Mesa developers - agreed that since khronos has essentially
deprecated the GL matrix API (by removing it from OpenGL 3 and
OpenGL-ES 2) it was appropriate to take full responsibility for all our
matrix manipulation.
- Developers should avoid modifying materials mid-scene.
* With the exception of material color changes, if you try and modify a
material that is referenced in the journal we will currently force a
journal flush. Note: you can assume that re-setting the same value for
a material property won't require a flush though.
- Several new --cogl-debug options have been added
* "disable-batching" can be used to identify bugs in the way that the
journal does its batching; of could this shouldn't ever be needed :-)
* "disable-vbos" can be used to test the VBO fallback paths where we
simply use malloc()'d buffers instead.
* "batching" lets you get an overview of how the journal is batching
your geometry and may help you identify ways to improve your
application performance.
* "journal" lets you trace all the geometry as it gets logged in the
journal, and all the geometry as its flushed from the journal.
Obviously an inconsistency can identify a bug, but the numbers may
help you verify application logic too.
* "disable-software-transform" as implied will instead use the driver
/GPU to transform quads by the modelview matrix.
Although committed separately a --clutter-debug=nop-picking option was
also added that lets you remove picking from the equation, which can
sometimes help make problem analysis more deterministic.
Although we wouldn't recommend developers try and interleve OpenGL drawing
with Cogl drawing - we would prefer patches that improve Cogl to avoid this
if possible - we are providing a simple mechanism that will at least give
developers a fighting chance if they find it necissary.
Note: we aren't helping developers change OpenGL state to modify the
behaviour of Cogl drawing functions - it's unlikley that can ever be
reliably supported - but if they are trying to do something like:
- setup some OpenGL state.
- draw using OpenGL (e.g. glDrawArrays() )
- reset modified OpenGL state.
- continue using Cogl to draw
They should surround their blocks of raw OpenGL with cogl_begin_gl() and
cogl_end_gl():
cogl_begin_gl ();
- setup some OpenGL state.
- draw using OpenGL (e.g. glDrawArrays() )
- reset modified OpenGL state.
cogl_end_gl ();
- continue using Cogl to draw
Again; we aren't supporting code like this:
- setup some OpenGL state.
- use Cogl to draw
- reset modified OpenGL state.
When the internals of Cogl evolves, this is very liable to break.
cogl_begin_gl() will flush all internally batched Cogl primitives, and emit
all internal Cogl state to OpenGL as if it were going to draw something
itself.
The result is that the OpenGL modelview matrix will be setup; the state
corresponding to the current source material will be setup and other world
state such as backface culling, depth and fogging enabledness will be also
be sent to OpenGL.
Note: no special material state is flushed, so if developers want Cogl to setup
a simplified material state it is the their responsibility to set a simple
source material before calling cogl_begin_gl. E.g. by calling
cogl_set_source_color4ub().
Note: It is the developers responsibility to restore any OpenGL state that they
modify to how it was after calling cogl_begin_gl() if they don't do this then
the result of further Cogl calls is undefined.
Although we wouldn't recommend developers try and interleve OpenGL drawing
with Cogl drawing - we would prefer patches that improve Cogl to avoid this
if possible - we are providing a simple mechanism that will at least give
developers a fighting chance if they find it necissary.
Note: we aren't helping developers change OpenGL state to modify the
behaviour of Cogl drawing functions - it's unlikley that can ever be
reliably supported - but if they are trying to do something like:
- setup some OpenGL state.
- draw using OpenGL (e.g. glDrawArrays() )
- reset modified OpenGL state.
- continue using Cogl to draw
They should surround their blocks of raw OpenGL with cogl_begin_gl() and
cogl_end_gl():
cogl_begin_gl ();
- setup some OpenGL state.
- draw using OpenGL (e.g. glDrawArrays() )
- reset modified OpenGL state.
cogl_end_gl ();
- continue using Cogl to draw
Again; we aren't supporting code like this:
- setup some OpenGL state.
- use Cogl to draw
- reset modified OpenGL state.
When the internals of Cogl evolves, this is very liable to break.
cogl_begin_gl() will flush all internally batched Cogl primitives, and emit
all internal Cogl state to OpenGL as if it were going to draw something
itself.
The result is that the OpenGL modelview matrix will be setup; the state
corresponding to the current source material will be setup and other world
state such as backface culling, depth and fogging enabledness will be also
be sent to OpenGL.
Note: no special material state is flushed, so if developers want Cogl to setup
a simplified material state it is the their responsibility to set a simple
source material before calling cogl_begin_gl. E.g. by calling
cogl_set_source_color4ub().
Note: It is the developers responsibility to restore any OpenGL state that they
modify to how it was after calling cogl_begin_gl() if they don't do this then
the result of further Cogl calls is undefined.
This function should only need to be called in exceptional circumstances
since Cogl can normally determine internally when a flush is necessary.
As an optimization Cogl drawing functions may batch up primitives
internally, so if you are trying to use raw GL outside of Cogl you stand a
better chance of being successful if you ask Cogl to flush any batched
geometry before making your state changes.
cogl_flush() ensures that the underlying driver is issued all the commands
necessary to draw the batched primitives. It provides no guarantees about
when the driver will complete the rendering.
This provides no guarantees about the GL state upon returning and to avoid
confusing Cogl you should aim to restore any changes you make before
resuming use of Cogl.
If you are making state changes with the intention of affecting Cogl drawing
primitives you are 100% on your own since you stand a good chance of
conflicting with Cogl internals. For example clutter-gst which currently
uses direct GL calls to bind ARBfp programs will very likely break when Cogl
starts to use ARBfb programs internally for the material API, but for now it
can use cogl_flush() to at least ensure that the ARBfp program isn't applied
to additional primitives.
This does not provide a robust generalized solution supporting safe use of
raw GL, its use is very much discouraged.
This function should only need to be called in exceptional circumstances
since Cogl can normally determine internally when a flush is necessary.
As an optimization Cogl drawing functions may batch up primitives
internally, so if you are trying to use raw GL outside of Cogl you stand a
better chance of being successful if you ask Cogl to flush any batched
geometry before making your state changes.
cogl_flush() ensures that the underlying driver is issued all the commands
necessary to draw the batched primitives. It provides no guarantees about
when the driver will complete the rendering.
This provides no guarantees about the GL state upon returning and to avoid
confusing Cogl you should aim to restore any changes you make before
resuming use of Cogl.
If you are making state changes with the intention of affecting Cogl drawing
primitives you are 100% on your own since you stand a good chance of
conflicting with Cogl internals. For example clutter-gst which currently
uses direct GL calls to bind ARBfp programs will very likely break when Cogl
starts to use ARBfb programs internally for the material API, but for now it
can use cogl_flush() to at least ensure that the ARBfp program isn't applied
to additional primitives.
This does not provide a robust generalized solution supporting safe use of
raw GL, its use is very much discouraged.
Previously we would call _cogl_material_pre_change_notify unconditionally, but
now we wait until we really know we are removing a layer before notifying the
change, which will require a journal flush.
Since the convenience functions cogl_set_source_color4ub and
cogl_set_source_texture share a single material, cogl_set_source_color4ub
always calls cogl_material_remove_layer. Often this is a NOP though and
shouldn't require a journal flush.
This gets performance back to where it was before reverting the per-actor
material commits.
Previously we would call _cogl_material_pre_change_notify unconditionally, but
now we wait until we really know we are removing a layer before notifying the
change, which will require a journal flush.
Since the convenience functions cogl_set_source_color4ub and
cogl_set_source_texture share a single material, cogl_set_source_color4ub
always calls cogl_material_remove_layer. Often this is a NOP though and
shouldn't require a journal flush.
This gets performance back to where it was before reverting the per-actor
material commits.
This reverts commit 8cf42ea8ac5c05f6b443c453f9c6c2a3cd75acfa.
Since the journal puts material colors in the vertex array accumulated for
drawing we don't need to flush the journal simply due to color changes which
means using cogl_set_source_color4ub is no longer a concern.
This reverts commit 85243da382025bd516937c76a61b8381f6e74689.
Since the journal puts material colors in the vertex array accumulated for
drawing we don't need to flush the journal simply due to color changes
which means using cogl_set_source_color4ub is no longer a concern.
Before any cogl vertex buffer drawing we call
enable_state_for_drawing_buffer which sets up the GL state, but we weren't
disabling unsed client texture coord arrays.
Before any cogl vertex buffer drawing we call
enable_state_for_drawing_buffer which sets up the GL state, but we weren't
disabling unsed client texture coord arrays.
