summaryrefslogtreecommitdiff
path: root/cogl/cogl-error.c
Commit message (Collapse)AuthorAgeFilesLines
* This re-licenses Cogl under the MIT licenseRobert Bragg2014-01-141-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This follows up on the proposal that was sent to the Cogl mailing list to re-license from the LGPL to the MIT license: http://lists.freedesktop.org/archives/cogl/2013-December/001465.html Note: there was a copyright assignment policy in place for Clutter (and therefore Cogl which was part of Clutter at the time) until the 11th of June 2010 and so we only checked the details after that point (commit 0bbf50f905) For each file, authors were identified via this Git command: $ git blame -p -C -C -C20 -M -M10 0bbf50f905..HEAD We received blanket approvals for re-licensing all Red Hat and Collabora contributions which reduced how many people needed to be contacted individually: - http://lists.freedesktop.org/archives/cogl/2013-December/001470.html - http://lists.freedesktop.org/archives/cogl/2014-January/001536.html Individual approval requests were sent to all the other identified authors who all confirmed the re-license on the Cogl mailinglist: http://lists.freedesktop.org/archives/cogl/2014-January As well as updating the copyright header in all sources files, the COPYING file has been updated to reflect the license change and also document the other licenses used in Cogl such as the SGI Free Software License B, version 2.0 and the 3-clause BSD license.
* Log a fatal error when an error is propagated to a NULL error argumentNeil Roberts2013-06-271-1/+4
| | | | | | | | | | Unlike in GError, the policy in Cogl for when NULL is passed as the CoglError argument is that the program should abort with a fatal error. Previously however any errors that were being propagated were being silently dropped if the application passed NULL. This patch fixes it to also log a fatal error in that case. Reviewed-by: Robert Bragg <robert@linux.intel.com>
* error: Don't allocate a new CoglError when propagatingNeil Roberts2012-11-271-3/+14
| | | | | | | | | | | | | | | | | | The _cogl_propagate_error() function takes ownership of the incoming error pointer so there's no need to allocate a new error when passing it on. The errors can potentially be passed up from a number of layers so it seems worthwhile to avoid the allocation. The _cogl_propagate_gerror() function was previously using _cogl_propagate_error(). Presumably this would not have worked because that function would try to free the error from glib using cogl_error_free but that would use the wrong free function and thus the wrong slice allocator. The GError propagating function is only used when gdk-pixbuf is enabled which now requires glib support anyway so we can just avoid defining the function when compiling without glib. Reviewed-by: Robert Bragg <robert@linux.intel.com>
* Fix spelling of _cogl_propagate_errorNeil Roberts2012-11-271-3/+3
| | | | | | ‘Propagate’ was misspelled as ‘propogate’. Reviewed-by: Robert Bragg <robert@linux.intel.com>
* Allow propogation of OOM errors to appsRobert Bragg2012-11-261-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Adds CoglError apiRobert Bragg2012-09-071-0/+109
Although we use GLib internally in Cogl we would rather not leak GLib api through Cogl's own api, except through explicitly namespaced cogl_glib_ / cogl_gtype_ feature apis. One of the benefits we see to not leaking GLib through Cogl's public API is that documentation for Cogl won't need to first introduce the Glib API to newcomers, thus hopefully lowering the barrier to learning Cogl. This patch provides a Cogl specific typedef for reporting runtime errors which by no coincidence matches the typedef for GError exactly. If Cogl is built with --enable-glib (default) then developers can even safely assume that a CoglError is a GError under the hood. This patch also enforces a consistent policy for when NULL is passed as an error argument and an error is thrown. In this case we log the error and abort the application, instead of silently ignoring it. In common cases where nothing has been implemented to handle a particular error and/or where applications are just printing the error and aborting themselves then this saves some typing. This also seems more consistent with language based exceptions which usually cause a program to abort if they are not explicitly caught (which passing a non-NULL error signifies in this case) Since this policy for NULL error pointers is stricter than the standard GError convention, there is a clear note in the documentation to warn developers that are used to using the GError api. Reviewed-by: Neil Roberts <neil@linux.intel.com>