The Clutter backend split is opaque enough that should allow us to just
build all possible backends inside the same shared object, and select
the wanted backend at initialization time.
This requires some work in the build system, as well as the
initialization code, to remove duplicate functions that might cause
conflicts at build and link time. We also need to defer all the checks
of the internal state of the platform-specific API to run-time type
checks.
This is mostly a stub, starting point for a one-stop Cogl
micro-benchmarking tool. The first test it adds is one that tries to
hammer the Cogl journal, but no doubt there are lots of other things we
should be regularly testing. Currently the aim is that the tool will be
able to also generate reports which we can collect to keep track of
performance changes over time.
The tests/accessibility, tests/micro-bench and the examples directory
in the coobook create a lot of non-installed binaries. Since we know who
they are, and we ignore them, we can auto-generate the ignore files as
well.
The rest of Clutter is covered by the main ignore file.
This adds a separate variable name "CLUTTER_SONAME_INFIX" to define the
infix for the clutter library that gets linked. Currently the WINSYS
corresponds to the directory we enter when building to compile the
window system and input support, but it is desirable to be able to
define multiple flavours that use the same WINSYS but should result in
different library names.
For example we are planning to combine the eglx and eglnative window
systems into one "egl" winsys but we will need to preserve the current
library names for the eglx and eglnative flavours.
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.
In order to be ready for the next major version of GLib we need to
disable single header inclusion by using the G_DISABLE_SINGLE_INCLUDES
define in the build process.
The maintainer compiler flags we use trigger warnings and errors
in the autogenerated code that gtk-doc creates to scan the header
and source files. Since we cannot control that, and we must run
a distcheck with both --enable-gtk-doc and --enable-maintainer-flags
turned on, we need to use less-strict compiler flags when inside
the doc/reference subdirectories.
The way to do this is to split the maintainer compiler flags into
their own Makefile variable, called MAINTAINER_CFLAGS. The we
can use $(MAINTAINER_CFLAGS) in the INCLUDES or _CFLAGS sections
of each part of the source directories we wish to check with the
anal retentiveness suited for maintainers.
framework
* configure.ac:
* tests/*:
The tests have been reorganised into different categories: conformance,
interactive and micro benchmarks.
- conformance tests can be run as part of automated tests
- interactive tests are basically all the existing tests
- micro benchmarks focus on a single performance metric
I converted the timeline tests to conformance tests and also added some
tests from Neil Roberts and Ebassi.
Note: currently only the conformance tests use the glib test APIs,
though the micro benchmarks should too.
The other change is to make the unit tests link into monolithic binaries
which makes the build time for unit tests considerably faster. To deal
with the extra complexity this adds to debugging individual tests I
have added some sugar to the makefiles so all the tests can be run
directly via a symlink and when an individual test is run this way,
then a note is printed to the terminal explaining exactly how that test
may be debugged using GDB.
There is a convenience make rule: 'make test-report', that will run all
the conformance tests and hopefully even open the results in your web
browser. It skips some of the slower timeline tests, but you can run
those using 'make full-report'
