Commit Graph

5 Commits

Author SHA1 Message Date
Neil Roberts
24412798dc Revert "Revert "Remove the framebuffer's stack of clip stacks""
This reverts commit bc41489336.

The reason this was causing problems for Clutter is that it defines
COGL_ENABLE_EXPERIMENTAL_2_0_API which is meant to cause the Cogl
headers not to declare the deprecated API. The reverted patch moved
some additional clipping API to a deprecated header which was
previously being used by Clutter. Clutter was still successfully
compiling but with some warnings for the missing function
declarations. However when the binary is run the clipping would get
completely messed up because it would assume all of the arguments to
the functions are integers instead of floats and the wrong values
would be passed.

Clutter now has commit to make it use the 2.0 API instead of the
deprecated functions so the revert is no longer necessary.

https://git.gnome.org/browse/clutter/commit?id=705640367a5c2ae21405806bfa

Reviewed-by: Robert Bragg <robert@linux.intel.com>
2013-12-04 17:22:01 +00:00
Jasper St. Pierre
bc41489336 Revert "Remove the framebuffer's stack of clip stacks"
This reverts commit ae9cd7ca01.

Pushing this for now so we can get gnome-shell working again without
memory corruption. Let's push a proper fix later for everybody.
2013-12-02 23:32:48 -05:00
Neil Roberts
ae9cd7ca01 Remove the framebuffer's stack of clip stacks
There used to be a function called cogl_clip_stack_save in the public
API which was used when temporarily switching to an offscreen buffer
to save the clip state. This is no longer necessary because each
framebuffer has its own clip stack anyway so the function was removed
in master. However the code to maintain the stack of stacks was
retained. This patch removes it in an effort to simplify the code.

On the 1.18 branch this function is deprecated and the documentation
says that it does nothing. However that is incorrect because it does
actually the push clip stack. I think it would be safe to backport
this patch to the 1.18 branch and actually make it do nothing like it
is documented to do.

https://bugzilla.gnome.org/show_bug.cgi?id=719546
(cherry picked from commit 8655027fdcf03b02fcbbb02d179a0a88ed79c5b3)

This patch has some extra changes while backporting to the 1.18
branch. Here the cogl-clip-state file still contained some deprecated
functions. Instead of deleting the file completely it has been moved
to the deprecated folder. The declarations for this functions have
been moved from cogl1-context.h to a new deprecated/cogl-clip-state.h
header.

Conflicts:
	cogl/Makefile.am
	cogl/cogl-clip-state.c

Reviewed-by: Robert Bragg <robert@linux.intel.com>
2013-11-29 16:35:58 +00:00
Robert Bragg
6436cd073d Declare interface types as void and remove cast macros
This declares the interface types CoglFramebuffer, CoglBuffer,
CoglTexture, CoglMetaTexture and CoglPrimitiveTexture as void when
including the public cogl.h header so that users don't have to use lots
of C type casts between instance types and interface types.

This also removes all of the COGL_XYZ() type cast macros since they do
nothing more than compile time type casting but it's less readable if
you haven't seen that coding pattern before.

Unlike with gobject based apis that use per-type macros for casting and
performing runtime type checking we instead prefer to do our runtime
type checking internally within the front-end public apis when objects
are passed into Cogl. This greatly reduces the verbosity for users of
the api and may help reduce the chance of excessive runtime type
checking that can sometimes be a problem.

(cherry picked from commit 248a76f5eac7e5ae4fb45208577f9a55360812a7)

Since we can't break the 1.x api this version of the patch actually
defines compatible NOP macros within deprecated/cogl-type-casts.h
2013-11-27 19:33:44 +00:00
Robert Bragg
fa855b7c45 Start clearly separating deprecated code
This makes a start on clearly factoring the deprecated code of core Cogl
into a deprecated/ directory. Ideally we want to get to the point where
all code here can be re-worked in terms of the public 2.0 api so that it
can be kept indefinitely for cogl 1.x api compatibility without
cluttering the core code base itself. If we can do this then we can
avoid maintaining the Cogl 1.x branches in parallel with master which
would reduce the maintenance effort.
2013-09-23 18:38:49 +01:00