Two of the meta texture constructors which take a flags parameter were
ignoring the COGL_TEXTURE_NO_AUTO_MIPMAP flag when creating an
underlying CoglTexture2D. These have now been fixed to call
cogl_primitive_texture_set_auto_mipmap after constructing the texture.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds public constructors which take a CoglBitmap to all primitive
texture types. This constructor should be considered the canonical
constructor for initializing the texture with data because it should
be possible to wrap any type of data in a CoglBitmap. Having at least
this single constructor avoids the need to have an explosion of
constructors such as new_from_data, new_from_pixel_buffer and
new_from_file etc.
The already available internal bitmap constructor for CoglTexture2D
has had its flags parameter removed under the assumption that flags do
not make sense for primitive textures. The meta constructor
cogl_texture_new_from_bitmap now just explicitly calls set_auto_mipmap
after constructing the texture depending on the value of the
COGL_TEXTURE_NO_AUTO_MIPMAP flag.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This interface represents any textures that are backed by a single
texture in GL and that can be used directly with the
cogl_framebuffer_draw_attributes family of functions. This currently
equates to CoglTexture2D, CoglTexture3D and CoglTextureRectangle.
The interface currently has only one method called
cogl_primitive_set_auto_mipmap. This replaces the
COGL_TEXTURE_NO_AUTO_MIPMAP flag from the CoglTextureFlags parameter
in the constructors. None of the other flags in CoglTextureFlags make
sense for primitive textures so it doesn't seem like a good idea to
need them for primitive constructors.
There is a boolean in the vtable to mark whether a texture type is
primitive which the new cogl_is_primitive function uses. There is also
a new texture virtual called set_auto_mipmap which is only required to
be implemented for primitive textures.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a context member to CoglBitmap which stores the context it
was created with. That way it can be used in texture constructors
which use a bitmap. There is also an internal private function to get
the context out of the bitmap which all of the texture constructors
now use. _cogl_texture_3d_new_from_bitmap has had its context
parameter removed so that it more closely matches the other bitmap
constructors.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
The previous code to initialise the depth state on the default
pipeline wasn't initialising the magic number. If you later tried to
retrieve the depth state using cogl_pipeline_get_depth_state you would
end up with an invalid depth state struct and you would just get
warnings if you tried to use it for anything. This patch just replaces
the initialisation with a call to cogl_depth_state_init because it
uses the same values anyway.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
get_texture_bits_via_offscreen does not check the return value of
cogl_framebuffer_read_pixels_into_bitmap which results into never
using the fallback path texture_get_cb.
cogl_framebuffer_read_pixels_into_bitmap does not check whether the framebuffer
is properly allocated though; so fix that as well.
https://bugzilla.gnome.org/show_bug.cgi?id=673137
Reviewed-by: Neil Roberts <neil@linux.intel.com>
This extension lets you upload texture data from a subregion of a
buffer by passing GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_PIXELS and
GL_UNPACK_SKIP_ROWS to glPixelStore. When this extension is available
the GLES texture driver will now avoid making a copy of the bitmap
when a subregion is used.
Note that Mesa doesn't currently advertise this extension but I've
made a patch to propose it:
http://lists.freedesktop.org/archives/mesa-dev/2012-March/020191.html
This extension allows an application to upload data in BGRA format. We
can use this to avoid a conversion in Cogl whenever it is given BGRA
data. This is quite useful when uploading data generated by Cairo
because at least on little-endian architectures that ends up as BGRA.
The patch just makes the pixel_format_to_gl implementation return
GL_BGRA_EXT for the data format and internal format whenever
COGL_PIXEL_FORMAT_BGRA_8888{,_PRE} is used.
A small caveat with this patch is that once a texture is created as
GL_BGRA, when later using glTexSubImage2D to update the texture it
must always be given data as GL_BGRA. Currently this just works out
because we store the internal format of a texture as a CoglPixelFormat
and we already swizzle the data if it does not match exactly on GLES.
However if we later switch to using a different enum for internal
formats then we might lose the ability to store the component ordering
so we'll have to think of another way to do this.
Cogl already had a vtable for the texture driver. This ended up being
used for some things that are not strictly related to texturing such
as converting between pixel formats and GL enums. Some other functions
that are driver dependent such as updating the features were not
indirected through a vtable but instead switched directly by looking
at the ctx->driver enum value. This patch normalises to the two uses
by adding a separate vtable for driver functions not related to
texturing and moves the pixel format conversion functions to it from
the texture driver vtable. It also adds a context parameter to all of
the functions in the new driver vtable so that they won't have to rely
on the global context.
It looks like the then-clause of the AS_IF macro needs to be in square
brackets otherwise the configure script gets generated wrong and you
get this output when you run it:
configure: line 17339: COGL_PANGO_DEP_CFLAGS: command not found
configure: line 17340: C: command not found
configure: line 17341: COGL_PANGO_DEP_LIBS: command not found
configure: line 17342: linker: command not found
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Because the wayland-client-protocol.h header defines symbols that
collide with the wayland-server-protocol.h header we allow applications
to explicitly ensure that they are only including one at a time by
exposing corresponding <cogl/cogl-wayland-client.h> and
<cogl/cogl-wayland-server.h> headers. This also adds a missing guard to
cogl-texture-2d.h that it isn't included directly.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The fallback code using stb-image.c was missed out in the upgrade to
cogl_bitmap_new_for_data from commit d18b59d9e6 so it wouldn't
compile.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
• The documentation for the framebuffer and texture interfaces had a
mis-matching open and close <note> tag so DocBook got upset and the
whole documentation disappeared.
• A lot of symbols from the cogl_framebuffer_* interface were missing
from the cogl-2.0-experimental-sections.txt file.
• cogl_framebuffer_frustum had the wrong version in its Since tag:
Reviewed-by: Robert Bragg <robert@linux.intel.com>
_cogl_framebuffer_draw_multitextured_rectangles had a typo in the
function name in the declaration so it was generating a lot of
compile warnings.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds experimental 2.0 api replacements for the cogl_rectangle[_*]
functions that don't depend on having a current pipeline set on the
context via cogl_{set,push}_source() or having a current framebuffer set
on the context via cogl_push_framebuffer(). The aim for 2.0 is to switch
away from having a statefull context that affects drawing to having
framebuffer drawing apis that are explicitly passed a framebuffer and
pipeline.
To test this change several of the conformance tests were updated to use
this api instead of cogl_rectangle and
cogl_rectangle_with_texture_coords. Since it's quite laborious going
through all of the conformance tests the opportunity was taken to make
other clean ups in the conformance tests to replace other uses of
1.x api with experimental 2.0 api so long as that didn't affect what was
being tested.
Fix the situation where glib-mkenums isn't located correctly when COGL
is not built in a root folder of a drive (ex: COGL is not unpacked in
c:\ or D:\, but in c:\blah or d:\blah)
This was causing the DocBook for the documentation to be invalid so
all of the framebuffer documentation disappeared.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
This adds a public convenience wrapper around
cogl_framebuffer_read_pixels_into_bitmap which allocates a temporary
CoglBitmap to read into the application's own buffer. This can only be
used for the 99% common case where the rowstride is exactly the
bpp*width and the source is the color buffer.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
In theory none of the journal flushing code should be using anything
that relies on the global framebuffer stack because it should all be
using the new 2.0-style API which explicitly mentions the target
framebuffer. Eventually we want to get rid of the framebuffer stack so
we might as well remove the push and pop now.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Previously when adding a quad to the journal it would assume the
journal belongs to the framebuffer at the top of the framebuffer stack
and store a reference to that. We eventually want to get rid of the
framebuffer stack so we should avoid using it here. The journal now
takes a pointer back to the framebuffer in its constructor and it
always retains the pointer. As was done previously, the journal still
does not take a reference on the framebuffer unless it is non-empty so
it does not create a permanent circular reference.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
_cogl_shader_compile_real spews a warning when
shader compilation fails if COGL_GL_DEBUG is
defined. This warning is never freed.
https://bugzilla.gnome.org/show_bug.cgi?id=672243
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The 1.0 wrapper for cogl_path_curve_to was using the wrong value for
y_1 so it wouldn't work.
The patch was written by Dénes Almási.
https://bugzilla.gnome.org/show_bug.cgi?id=672174
Reviewed-by: Neil Roberts <neil@linux.intel.com>
The KMS platform accesses all of it's GL symbols via the indirection
through the Cogl context so there is no need to link against it
directly. This helps when trying to use Cogl with GLES where pulling
in Xlib via libGL is potentially a problem.
Reviewed-by: Robert Bragg <robert@linux.intel.com>
We initially assumed that copy_sub_buffer is synchronized on
which is only the case for a subset of GPUs for example it is not
synchronized on INTEL gen6 and gen7, so we remove this assumption
for now.
We should have a specific driver / GPU whitelist if we want to enable
this.
https://bugzilla.gnome.org/show_bug.cgi?id=669122
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
