Hi,<div><br></div><div>I'm not sure if this is the appropriate list for this, but here goes.</div><div><br></div><div>I am working on a Clutter-based application on Windows 7  We've tested with Clutter 1.8.4 / COGL 1.8.0, and with Clutter 1.10.8 / COGL 1.10.2.  We are currently running into a problem when allocating a new COGL texture that causes a resizing or reorganization of the atlas. Even though the texture creation appears to succeed, all of the images are gone. The screen is black except for the text. The only indication of a failure is a warning that a framebuffer could not be created.</div>
<div><br></div><div>This normally happens when the atlas is being resized to 4096 x 8192, but we've seen it with atlases from 2048 x 4096 and sometimes not until resizing to 8192 x 8192. It happens a lot sooner when GPU-heavy applications like Windows Media Player are running at the same time. (We have some machines with Intel HD graphics drivers and some machines with NVIDIA.)</div>
<div><br></div><div>I've traced it down to an out of memory error from OpenGL in cogl_texture_2d_new_with_size()  when we create the destination texture for the new atlas. The out of memory error is not detected, and the destination texture appears to be created. Later when try_creating_fbo() tries to create the framebuffer attaching the texture results in an INCOMPLETE_ATTACHMENT error, and the blit mode falls back to the "copy-tex-sub-image", with the unsatisfactory results described above.</div>
<div><br></div><div>We can work around this by modifying the COGL code to check for out of memory errors when resizing the atlas. This seems to give us much better behaviour, but it's not a complete solution. (I'm not experienced enough with the code-base to know where to place the checking so that it is thorough, and has minimal impact on performance.) And we can delay the occurrence of this error by doing a better job of discarding our textures when we do not need them. (Unfortunately, the application was originally written to manage the textures itself, instead of leaving it to clutter.)</div>
<div><br></div><div>We would like a better way of detecting when we run out of graphics memory, so that we can provide a meaningful error message to the user, and do a graceful recovery.</div><div><br></div><div>Has anyone else run into issues with COGL running out of graphics memory and come up with an effective way to detect and deal with it?</div>
<div><br></div><div>Thanks in advance for any information or direction.</div><div><br></div><div>Roy</div><div><br></div>