cogl: Fix the include path in driver/*/Makefile.am looks goodAdd _cogl_texture_2d_externally_modified looks goodAdd COGL_{OBJECT,HANDLE}_DEFINE_WITH_CODE looks goodcogl-texture: List texture subclass types rather than hardcoding them looks goodcogl-texture: Replace the ensure_mipmaps virtual with pre_paint I'd like to avoid having any more exposure of the CoglMaterialLayer handles outside cogl-material.c. This isn't any worse than _cogl_material_layer_ensure_mipmaps which your replacing so I don't think it's critical that this should be changed, but I think eventually we should have some API that takes a layer index instead. I wonder if we could do more to document where pre_paint needs to be called. I can see from examining the code so it's not too big a deal but it would be nice if the members of struct _CoglTextureVtable were each documented. (I don't mean they all need to all be done now but we could make a start with the new pre_paint virtual.) I think it would be good if the documentation in struct _CoglTextureVtable were geared towards developers implementing new backends. The fact that this function can completely change the storage of a texture is an important detail that I don't think would be entirely clear to a new developer. It looks like it's a step in the direction of the big comment I added in cogl-primitives.c, maybe you could update this comment.cogl: Add a struct for winsys-specific data to CoglContext not quite sure it warrants a separate commit for this, but it seems ok.cogl: Add the infrastructure for checking for winsys extensions looks goodPass all Xlib events through Cogl looks goodcogl-texture: Avoid premult conversion if the dst format has no alpha looks goodcogl: Add _cogl_xlib_{,un}trap_errors I wonder if _cogl_xlib_trap_errors should throw an assert/warning if old_error_handler ends up == error_handler given that the implementation can't cope with nested traps.test-pixmap: Implement the --disable-x11 option looks goodtest-pixmap: Enable automatic updates for the hand looks goodtest-pixmap: Add a --disable-animation option looks goodtest-pixmap: Draw something more interesting when the mouse is clicked commit message typos (The word "to" just wasn't getting though to the hands) "to see so it's easy miss. This patch changes it draw a thick black" ^to? ^to?test-pixmap: Use the 'm' key to toggle texture quality looks good - though it looks like test-pixmap is getting quite complex and I wonder if we need to instead be writing conformance tests.Add --include=xlib-2.0 for the introspection data of Cogl looks goodAdd a CoglTexturePixmapX11 texture backend We could consider nicking the X region code (or the cairo rectangle code) instead of having a CoglDamageRectangle type. Instead of using the XDamageReportNonEmpty report level for automatic updates we should probably use XDamageReportBoundingBox because then we could aim to have Mutter use the automatic updates mechanism we offer. Can we keep the cogl_texture_pixmap_x11_ API as experimental or internal only API for now; I'm not totally confident about how we should handle the damage objects/automatic updates. I wonder if we could have: cogl_texture_pixmap_x11_set_damage_object (CoglHandle texture, guint32 damage_object_xid, CoglTexturePixmapX11DamageReportLevel level); So if you simply use cogl_texture_pixmap_x11_set_automatic_update () then by default we should use the BoundingBox report level, but optionally a higher level component that also needs to process the damage events can instead create its own object and ask Cogl to use that instead.clutter-{glx,x11}-texture-pixmap: Use CoglTexturePixmapX11 It doesn't seem right that clutter-x11-texture-pixmap.c creates a Damage object *and* we pass TRUE to cogl_texture_pixmap_x11_new to enable automatic updates which will create a second damage object so the server will have to report double the number of events to us? If we had something like the above cogl_texture_pixmap_x11_set_damage_object we could just have one damage object.