CoglMetaTexture is an interface for dealing with high level textures
that may be comprised of one or more low-level textures internally. The
interface allows the development of primitive drawing APIs that can draw
with high-level textures (such as atlas textures) even though the
GPU doesn't natively understand these texture types.
There is currently just one function that's part of this interface:
cogl_meta_texture_foreach_in_region() which allows an application to
resolve the internal, low-level textures of a high-level texture.
cogl_rectangle() uses this API for example so that it can easily emulate
the _REPEAT wrap mode for textures that the hardware can't natively
handle repeating of.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
G_DISABLE_DEPRECATED is only intended for developers of Cogl and it
sometimes breaks the build for people just trying to build a
release. This patch adds an option to enable deprecated Glib
features. By default it is enabled for non-git versions of Cogl.
The patch is based on similar code in Clutter except it adds the flags
to COGL_EXTRA_CFLAGS instead of having a separate variable.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
It seems that cogl-context-private.h needs to be included before including
any of the pipeline-related stuff to avoid build errors on C89 compilers.
This is due to the recent cogl-pipeline decoupling, seems like.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
As part of the on going, incremental effort to purge the non type safe
CoglHandle type from the Cogl API this patch tackles most of the
CoglHandle uses relating to textures.
We'd postponed making this change for quite a while because we wanted to
have a clearer understanding of how we wanted to evolve the texture APIs
towards Cogl 2.0 before exposing type safety here which would be
difficult to change later since it would imply breaking APIs.
The basic idea that we are steering towards now is that CoglTexture
can be considered to be the most primitive interface we have for any
object representing a texture. The texture interface would provide
roughly these methods:
cogl_texture_get_width
cogl_texture_get_height
cogl_texture_can_repeat
cogl_texture_can_mipmap
cogl_texture_generate_mipmap;
cogl_texture_get_format
cogl_texture_set_region
cogl_texture_get_region
Besides the texture interface we will then start to expose types
corresponding to specific texture types: CoglTexture2D,
CoglTexture3D, CoglTexture2DSliced, CoglSubTexture, CoglAtlasTexture and
CoglTexturePixmapX11.
We will then also expose an interface for the high-level texture types
we have (such as CoglTexture2DSlice, CoglSubTexture and
CoglAtlasTexture) called CoglMetaTexture. CoglMetaTexture is an
additional interface that lets you iterate a virtual region of a meta
texture and get mappings of primitive textures to sub-regions of that
virtual region. Internally we already have this kind of abstraction for
dealing with sliced texture, sub-textures and atlas textures in a
consistent way, so this will just make that abstraction public. The aim
here is to clarify that there is a difference between primitive textures
(CoglTexture2D/3D) and some of the other high-level textures, and also
enable developers to implement primitives that can support meta textures
since they can only be used with the cogl_rectangle API currently.
The thing that's not so clean-cut with this are the texture constructors
we have currently; such as cogl_texture_new_from_file which no longer
make sense when CoglTexture is considered to be an interface. These
will basically just become convenient factory functions and it's just a
bit unusual that they are within the cogl_texture namespace. It's worth
noting here that all the texture type APIs will also have their own type
specific constructors so these functions will only be used for the
convenience of being able to create a texture without really wanting to
know the details of what type of texture you need. Longer term for 2.0
we may come up with replacement names for these factory functions or the
other thing we are considering is designing some asynchronous factory
functions instead since it's so often detrimental to application
performance to be blocked waiting for a texture to be uploaded to the
GPU.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Only cogl-pango needs a dependency on pangocairo so we are now careful to
separate the pangocairo pkg-config flags from the others so we can avoid
having libcogl builds refer to them.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Instead of storing four vertices per rectangle in the array for a
texture node in the display list, it now only stores two in a format
that is acceptable to cogl_rectangles_with_texture_coords. That way
it can pass the array directly to that function. That function has the
advantage over cogl_rectangle that it doesn't need to validate the
pipeline for every quad so it should be slightly faster.
When the texture node is being rendered with a CoglPrimitive we now
map the buffer and expand the rectangles into 4 vertices as the data
is copied.
https://bugzilla.gnome.org/show_bug.cgi?id=656303
Reviewed-by: Robert Bragg <robert@linux.intel.com>
When rendering text through a VBO, CoglPangoDisplayList now uses the
CoglPrimitive API instead of CoglVertexBuffer. CoglVertexBuffer is
just a layer on top of the attribute buffer API anyway so it should be
slightly faster.
https://bugzilla.gnome.org/show_bug.cgi?id=656303
Reviewed-by: Robert Bragg <robert@linux.intel.com>
At the moment, on make install, libcogl-pango will link to the
version of libcogl that is installed system wide. This leads to
interesting problems when the version installed system wide is
incompatible with the version of cogl being built.
E.g., when building cogl-1.7.4 (with --enable-cogl-pango and
--prefix=/usr) on a system that has cogl-1.7.2 installed in /usr:
$ make
[...]
$ ldd cogl-pango/.libs/libcogl-pango.so | grep cogl
libcogl.so.2 => /var/tmp/cogl-1.7.4/cogl/.libs/libcogl.so.2 (0x00007eff4bfb2000)
$ make DESTDIR=/var/tmp/cogl-1.7.4/dest install
[...]
$ ldd /var/tmp/cogl-1.7.4/dest/usr/lib64/libcogl-pango.so | grep cogl
libcogl.so.1 => /usr/lib64/libcogl.so.1 (0x00007f4647747000)
This problem can be avoided by reordering libcogl_pango_la_LIBADD
to ensure that during make installs' relinking phase, libtool looks
at the libcogl in the build directory before the system wide libcogl.
https://bugzilla.gnome.org/show_bug.cgi?id=655026
Reviewed-By: Robert Bragg <robert@linux.intel.com>
Reviewed-By: Emmanuele Bassi <ebassi@linux.intel.com>
The GL or GLES library is now dynamically loaded by the CoglRenderer
so that it can choose between GL, GLES1 and GLES2 at runtime. The
library is loaded by the renderer because it needs to be done before
calling eglInitialize. There is a new environment variable called
COGL_DRIVER to choose between gl, gles1 or gles2.
The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have
been changed so that they don't assume the ifdefs are mutually
exclusive. They haven't been removed entirely so that it's possible to
compile the GLES backends without the the enums from the GL headers.
When using GLX the winsys additionally dynamically loads libGL because
that also contains the GLX API. It can't be linked in directly because
that would probably conflict with the GLES API if the EGL is
selected. When compiling with EGL support the library links directly
to libEGL because it doesn't contain any GL API so it shouldn't have
any conflicts.
When building for WGL or OSX Cogl still directly links against the GL
API so there is a #define in config.h so that Cogl won't try to dlopen
the library.
Cogl-pango previously had a #ifdef to detect when the GL backend is
used so that it can sneakily pass GL_QUADS to
cogl_vertex_buffer_draw. This is now changed so that it queries the
CoglContext for the backend. However to get this to work Cogl now
needs to export the _cogl_context_get_default symbol and cogl-pango
needs some extra -I flags to so that it can include
cogl-context-private.h
This explicitly renames the cogl-2.0 reference manual to
cogl-2.0-experimental and renames the cogl-2.0 pkg-config file to
cogl-2.0-experimental.pc. Hopefully this should avoid
miss-understandings.
When rendering a box for an unknown glyph it would previously just use
the average glyph size for the font. This causes problems because the
size calculations for the layout assume a different size so it can end
up rendering outside of the expected ink rectangle. This patch changes
it to query the size of the glyph in the font. Pango should end up
reporting the size of what would be the hex box which should be the
same as the sized used for the extents calculation.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2599
This uses INTROSPECTION_COMPILER_ARGS to pass
--includedir=$(top_builddir)/cogl so when building the CoglPango typelib
the compiler can find the required Cogl-1.0.gir file.
cogl-pango is conceptually a separate library so it doesn't seem
appropriate to bundle the headers with all the other cogl headers. Also
in-tree the headers live in a cogl-pango directory so if we want
examples that can include cogl-pango consistently when built in or out
of tree using the convention #include <cogl-pango/cogl-pango.h> makes
that easy.
This adds a compatibility cogl/cogl-pango.h header that's will redirect
to cogl-pango/cogl-pango.h with a warning, or result in an error if
COGL_ENABLE_EXPERIMENTAL_2_0_API is defined.
When creating a new display list the pango renderer tries to add a
callback to the glyph cache so that it can be notified whenever the
atlas is reorganized. However it was always registering the callback
for the glyph cache which doesn't use mipmapping so if mipmapping is
enabled then it wouldn't work correctly.
This patch moves the two sets of caches (pipeline cache and glyph
cache) into one struct so that it's a little bit easier to determine
which pair to use in the code.
Some of the sources need to include <cogl/cogl-defines.h> which is in
the build directory. I think this directory gets added to the include
flags anyway by something so the actual building works but when
building the introspection data out of tree it was not included so it
failed to scan.
This removes all the remnants from being able to build Cogl standalone
while it was part of the Clutter repository. Now that Cogl has been
split out then standalone builds are the only option.
