Commit Graph

4 Commits

Author SHA1 Message Date
Neil Roberts
af0dc3431d Fix spelling of _cogl_propagate_error
‘Propagate’ was misspelled as ‘propogate’.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 5fb4a6178c3e64371c01510690d9de1e8a740bde)
2013-01-22 17:48:08 +00:00
Robert Bragg
f53fb5e2e0 Allow propogation of OOM errors to apps
This allows apps to catch out-of-memory errors when allocating textures.

Textures can be pretty huge at times and so it's quite possible for an
application to try and allocate more memory than is available. It's also
very possible that the application can take some action in response to
reduce memory pressure (such as freeing up texture caches perhaps) so
we shouldn't just automatically abort like we do for trivial heap
allocations.

These public functions now take a CoglError argument so applications can
catch out of memory errors:

cogl_buffer_map
cogl_buffer_map_range
cogl_buffer_set_data
cogl_framebuffer_read_pixels_into_bitmap
cogl_pixel_buffer_new
cogl_texture_new_from_data
cogl_texture_new_from_bitmap

Note: we've been quite conservative with how many apis we let throw OOM
CoglErrors since we don't really want to put a burdon on developers to
be checking for errors with every cogl api call. So long as there is
some lower level api for apps to use that let them catch OOM errors
for everything necessary that's enough and we don't have to make more
convenient apis more awkward to use.

The main focus is on bitmaps and texture allocations since they
can be particularly large and prone to failing.

A new cogl_attribute_buffer_new_with_size() function has been added in
case developers need to catch OOM errors when allocating attribute buffers
whereby they can first use _buffer_new_with_size() (which doesn't take a
CoglError) followed by cogl_buffer_set_data() which will lazily allocate
the buffer storage and report OOM errors.

Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit f7735e141ad537a253b02afa2a8238f96340b978)

Note: since we can't break the API for Cogl 1.x then actually the main
purpose of cherry picking this patch is to keep in-line with changes
on the master branch so that we can easily cherry-pick patches.

All the api changes relating stable apis released on the 1.12 branch
have been reverted as part of cherry-picking this patch so this most
just applies all the internal plumbing changes that enable us to
correctly propagate OOM errors.
2013-01-22 17:48:07 +00:00
Neil Roberts
ec03357e88 Add cogl_buffer_map_range()
This adds a buffer method to map a subregion of the buffer. This works
using the GL_ARB_map_buffer_range extension. If the extension is not
available then it will fallback to using glMapBuffer to map the entire
buffer and then just add the offset to the returned pointer.

cogl_buffer_map() is now just a wrapper which maps the entire range of
the buffer. The driver backend functions have been renamed to
map_range and they now all take the offset and size arguments.

When the COGL_BUFFER_MAP_HINT_DISCARD hint is used and the map range
extension is available instead of using glBufferData to invalidate the
buffer it will instead pass the new GL_MAP_HINT_INVALIDATE_BUFFER
flag. There is now additionally a COGL_BUFFER_MAP_HINT_DISCARD_REGION
hint which can be used if the application only wants to discard the
small region that is mapped. glMapBufferRange is always used if it is
available even if the entire buffer is being mapped because it seems
more robust to pass those flags then to call glBufferData.

Reviewed-by: Robert Bragg <robert@linux.intel.com>

(cherry picked from commit 55ca02b5ca9cafc750251ec974e0d6a536cb80b8)
2013-01-22 17:48:03 +00:00
Robert Bragg
b1ecfbf720 buffer: splits out GL specific code
As part of an on-going effort to be able to support non-opengl drivers
for Cogl this splits out the opengl specific code from cogl-buffer.c
into driver/gl/cogl-buffer-gl.c

Reviewed-by: Neil Roberts <neil@linux.intel.com>

(cherry picked from commit 4d7094a979ff2cbbe4054f4a44ca05fc41a9e447)
2013-01-22 17:47:59 +00:00