| 8f3960179c56767e5077be8337792bd4e244b7d7 |
|
01-Apr-2014 |
Francis Hart <fhart@nvidia.com> |
Use asynchronous lock/unlock API
The gralloc API now provides a way for using lock/unlock with the Android
explicit synchronisation concept. This changes updates the GraphicBuffer class
to also expose this functionality, and updates the Surface class to make use of
in line with the dequeueBuffer/queueBuffer mechanism.
This new behaviour is dependent on GRALLOC_MODULE_API_VERSION_0_3. If the local
gralloc module does not support this then the existing synchronous lock/unlock
mechanism will be used.
Change-Id: I8c3fd9592e0c5400ac9be84450f55a77cc0bbdc5
/frameworks/native/include/ui/GraphicBufferMapper.h
|
| 53ec72523a4083b88eaa13e2e720976523a7ebf8 |
|
09-May-2014 |
Greg Hackmann <ghackmann@google.com> |
Revert "Use asynchronous lock/unlock API"
This reverts commit 378ef07760eda717367d9429428c42d54d54d9a7.
Change-Id: I1de5ab973b5383633e75924fe90ac3ca8216c36a
/frameworks/native/include/ui/GraphicBufferMapper.h
|
| 378ef07760eda717367d9429428c42d54d54d9a7 |
|
01-Apr-2014 |
Francis Hart <fhart@nvidia.com> |
Use asynchronous lock/unlock API
The gralloc API now provides a way for using lock/unlock with the Android
explicit synchronisation concept. This changes updates the GraphicBuffer class
to also expose this functionality, and updates the Surface class to make use of
in line with the dequeueBuffer/queueBuffer mechanism.
This new behaviour is dependent on GRALLOC_MODULE_API_VERSION_0_3. If the local
gralloc module does not support this then the existing synchronous lock/unlock
mechanism will be used.
Change-Id: I77daa1beb197b63b1c2f281b8414ac4ae4b5b03c
/frameworks/native/include/ui/GraphicBufferMapper.h
|
| c43946b931de5dafd28f49963f9af78e05390b26 |
|
05-May-2013 |
Eino-Ville Talvala <etalvala@google.com> |
Add support for HAL_PIXEL_FORMAT_YCbCr_420_888
- Add fields to CpuConsumer::LockedBuffer for new information
- New lock methods for GraphicBuffer and GraphicBufferMapper for
the format
Bug: 8734880
Change-Id: If31f82c62d64b6942cf4cc6e5715585c03273f12
/frameworks/native/include/ui/GraphicBufferMapper.h
|
| 3330b203039dea366d4981db1408a460134b2d2c |
|
06-Oct-2009 |
Mathias Agopian <mathias@google.com> |
fix [2167050] glTexImage2D code path buggy in SurfaceFlinger
When EGLImage extension is not available, SurfaceFlinger will fallback to using
glTexImage2D and glTexSubImage2D instead, which requires 50% more memory and an
extra copy. However this code path has never been exercised and had some bugs
which this patch fix.
Mainly the scale factor wasn't computed right when falling back on glDrawElements.
We also fallback to this mode of operation if a buffer doesn't have the adequate
usage bits for EGLImage usage.
This changes only code that is currently not executed. Some refactoring was needed to
keep the change clean. This doesn't change anything functionaly.
/frameworks/native/include/ui/GraphicBufferMapper.h
|