Jesse Hall d58c304cc6 Clarify aborted updateTexImage use of fences ... When updateTexImage acquires a buffer but then aborts (due to an error or the buffer being rejected), it releases the newly-acquired buffer. It was passing the buffer slot's fences to releaseBuffer, even though they hadn't been created after the acquire yet. This wasn't a bug, since the fences would be cleared just after the buffer slot was last released, but explicitly passing null fences makes this clearer. Change-Id: I087f2ec3fd02c40f57782c1fca24eb9567e2943d		2012-06-28 17:08:42 -07:00
build	I am having second thoughts about 512m for the large heap size.	2012-06-08 13:02:09 -07:00
cmds	am 4f0dfaa7: am 9be7caf3: Merge "Include stack traces for certain native processes in bugreport." into jb-dev	2012-06-08 15:33:30 -07:00
data/etc	Move com.nxp.mifare to frameworks/native.	2012-04-12 21:24:08 -07:00
include	Return fence to client in dequeuBuffer	2012-06-28 17:08:42 -07:00
libs	Clarify aborted updateTexImage use of fences	2012-06-28 17:08:42 -07:00
opengl	Update ANativeWindow clients for sync	2012-06-20 15:48:30 -07:00
services	Transfer HWC release fences to BufferQueue	2012-06-21 22:21:12 -07:00
MODULE_LICENSE_APACHE2
NOTICE