The SDL API is far too limited for the windowing system needs of
Clutter; the status of the SDL backend was always experimental, and
since the Windows platform is supported by a native backend there is
no point in having the SDL backend around any more.
When using pkg-config to check for the x11 package compiler flags and
libraries we actually need to retrieve those values from the pc file.
This should also fix the issue with non-canonical installations of the
X11 headers and shared objects.
http://bugzilla.openedhand.com/show_bug.cgi?id=1966
The win32 backend now handles the WM_SETCURSOR message and sets a
fully transparent cursor if the cursor-visible property has been
cleared on the stage. The icon is stored in the library via a resource
file. The instance handle for the DLL is needed to load the resource
so there is now a DllMain function to grab the handle.
This adds gives Cogl a dedicated UProf context which will be linked together
with Clutter's context during clutter_init_real().
Initial timers cover _cogl_journal_flush and _cogl_journal_log_quad
You can explicitly ask for a report of Cogl statistics by exporting
COGL_PROFILE_OUTPUT_REPORT=1 but since the context is linked with Clutter's
the statisitcs will also be shown in the automatic Clutter reports.
• Make the manual a DevHelp book
• Make the generation of PDFs of the cookbook and the manual optional
• Consequently, make the hard dependency on jw optional
• Clean up the checks and build for the additional documentation
Instead of creating stand-alone HTML files, use XSLT to transform the
DocBook into a DevHelp file, so that we can read the Cookbook inside
DevHelp -- just like the API reference.
The "Clutter Cookbook" is a document designed to contain solutions
to common problems applications developers might encounter when using
Clutter. It is meant as a companion to the API reference but it
requires knowledge of the Clutter API and framework.
The main COGL header cogl.h is currently created at configure time
because it conditionally includes the driver-dependent defines. This
sometimes leads to a stale cogl.h with old definitions which can
break the build until you clean out the whole tree and start from
scratch.
We can generate a stable cogl-defines.h at build time from the
equivalent driver-dependent header and let cogl.h include that
file instead.
We should generate a ChangeLog for each minor version cycle, starting
from the Git import date (since before that we used ChangeLog-style
commit messages that don't really look good with the Git ones).
For this reason we can take Cairo's Makefile.am.changelog file and,
after tweaking it to fit our use case, let it generate the correct
ChangeLogs on dist.
Some changes to make COGL pass distcheck with Automake 1.11 and
anal-retentiveness turned up to 11.
The "major" change is the flattening of the winsys/ part of COGL,
which is built directly inside libclutter-cogl.la instead of an
intermediate libclutter-cogl-winsys.la object.
Ideally, the whole COGL should be flattened out using a
quasi-non-recursive Automake layout; unfortunately, the driver/
sub-section ships with identical targets and Automake cannot
distinguish GL and GLES objects.
As part of an incremental process to have Cogl be a standalone project we
want to re-consider how we organise the Cogl source code.
Currently this is the structure I'm aiming for:
cogl/
cogl/
<put common source here>
winsys/
cogl-glx.c
cogl-wgl.c
driver/
gl/
gles/
os/ ?
utils/
cogl-fixed
cogl-matrix-stack?
cogl-journal?
cogl-primitives?
pango/
The new winsys component is a starting point for migrating window system
code (i.e. x11,glx,wgl,osx,egl etc) from Clutter to Cogl.
The utils/ and pango/ directories aren't added by this commit, but they are
noted because I plan to add them soon.
Overview of the planned structure:
* The winsys/ API is the API that binds OpenGL to a specific window system,
be that X11 or win32 etc. Example are glx, wgl and egl. Much of the logic
under clutter/{glx,osx,win32 etc} should migrate here.
* Note there is also the idea of a winsys-base that may represent a window
system for which there are multiple winsys APIs. An example of this is
x11, since glx and egl may both be used with x11. (currently only Clutter
has the idea of a winsys-base)
* The driver/ represents a specific varient of OpenGL. Currently we have "gl"
representing OpenGL 1.4-2.1 (mostly fixed function) and "gles" representing
GLES 1.1 (fixed funciton) and 2.0 (fully shader based)
* Everything under cogl/ should fundamentally be supporting access to the
GPU. Essentially Cogl's most basic requirement is to provide a nice GPU
Graphics API and drawing a line between this and the utility functionality
we add to support Clutter should help keep this lean and maintainable.
* Code under utils/ as suggested builds on cogl/ adding more convenient
APIs or mechanism to optimize special cases. Broadly speaking you can
compare cogl/ to OpenGL and utils/ to GLU.
* clutter/pango will be moved to clutter/cogl/pango
How some of the internal configure.ac/pkg-config terminology has changed:
backendextra -> CLUTTER_WINSYS_BASE # e.g. "x11"
backendextralib -> CLUTTER_WINSYS_BASE_LIB # e.g. "x11/libclutter-x11.la"
clutterbackend -> {CLUTTER,COGL}_WINSYS # e.g. "glx"
CLUTTER_FLAVOUR -> {CLUTTER,COGL}_WINSYS
clutterbackendlib -> CLUTTER_WINSYS_LIB
CLUTTER_COGL -> COGL_DRIVER # e.g. "gl"
Note: The CLUTTER_FLAVOUR and CLUTTER_COGL defines are kept for apps
As the first thing to take advantage of the new winsys component in Cogl;
cogl_get_proc_address() has been moved from cogl/{gl,gles}/cogl.c into
cogl/common/cogl.c and this common implementation first trys
_cogl_winsys_get_proc_address() but if that fails then it falls back to
gmodule.
Following bug #1762, the syntax of g-ir-scanner was changed in
gobject-introspection, so Clutter does not build anymore with 0.6.4.
See the bugzilla bug:
http://bugzilla.gnome.org/show_bug.cgi?id=591669
GObject-Introspection now uses a different mechanism to extract the
SONAME when building the gir file and it needs the libtool archive as
option.
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>