summaryrefslogtreecommitdiffstats
path: root/include/GLES
diff options
context:
space:
mode:
authorIan Romanick <[email protected]>2015-11-13 10:51:01 -0800
committerIan Romanick <[email protected]>2016-03-01 11:07:19 -0800
commitf76462cb6ffbf70a10ae216c97e85ee195ce1d5b (patch)
tree40ed91eb2caa56ef0ad00fd1e4951bd01d6f8b7e /include/GLES
parentfed9b0ed5a6856ac109ffee5116b988bc0669e5b (diff)
meta: Save and restore the framebuffer using gl_framebuffer instead of GL API object handle
Some meta operations can be called recursively. Future changes (the "Don't pollute the ... namespace" changes) will cause objects with invalid names to be used. If a nested meta operation tries to restore an object named 0xDEADBEEF, it will fail. This also fixes another latent bug in meta. In a multithreaded, multicontext application, one thread can delete an object that is bound in another thread. That object continues to exist until it is unbound (i.e., its refcount drops to zero). Meta unbinds objects all over the place. As a result, the rebind in _mesa_meta_end could fail because the object vanished! See https://bugs.freedesktop.org/show_bug.cgi?id=92363#c8. Using _mesa_reference_<object type> to save and restore the objects prevents the refcount from going to zero. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <[email protected]>
Diffstat (limited to 'include/GLES')
0 files changed, 0 insertions, 0 deletions