now that sf handles more of the screen on/off state, we don't want to abort
because/if the animation fails for some reason (which will be the case on the
emulator).
Change-Id: I239e0a39cf8aff3074647e82db92de4a0bf0e494
Merge commit '9a12a3c8d4bb20042cf69e07d268e3a04ac71f96'
* commit '9a12a3c8d4bb20042cf69e07d268e3a04ac71f96':
Remove dead code, and make the animation a setting.
turn off the electron beam
Merge commit '011b5bcc0355338b7ff906656282a54ffaa04b5a' into gingerbread-plus-aosp
* commit '011b5bcc0355338b7ff906656282a54ffaa04b5a':
implement part of [3094280] New animation for screen on and screen off
Merge commit 'ba799098608c7be8ff1e18adfa7dc1f452205a7e' into gingerbread-plus-aosp
* commit 'ba799098608c7be8ff1e18adfa7dc1f452205a7e':
Remove dead code, and make the animation a setting.
turn off the electron beam
Merge commit '5d477279e6e41c9d61abe66dcded5c57a51e2c78'
* commit '5d477279e6e41c9d61abe66dcded5c57a51e2c78':
fix a bug where FLIP_H would do a 180 rotation
Bug #3081600
The OpenGL renderer in libhwui uses a single EGL context per process and
thus create it with an RGBA 8888 EGL configuration. To ensure that all
windows are compatible with this configuration, this change modifies
the window manager and SurfaceFlinger.
The window manager now checks the window's flags and if the window is
hardware accelerated, it forces the window's pixel format to be
translucent when creating the surface. The window itself is still
marked as opaque if we know that the window will be opaque on screen.
This keeps existing optimizations in place.
Similarly in SurfaceFlinger, a translucent Surface can now be created
with the Surface.OPAQUE flag, indicating SurfaceFlinger that the surface
does not require blending, despite its RGBA 8888 configuration.
Change-Id: Ic747b6b12564ba064412d842117880fcc199eb7c
Merge commit 'cf6b2765ae7ea6305754e253264012b8f0498f7b' into gingerbread-plus-aosp
* commit 'cf6b2765ae7ea6305754e253264012b8f0498f7b':
fix a bug where FLIP_H would do a 180 rotation
Merge commit 'd0528b74b6de87c415ea498095e142d52c68875b' into gingerbread-plus-aosp
* commit 'd0528b74b6de87c415ea498095e142d52c68875b':
deliver invalidate messages AFTER other messages
because invalidate messages were always handled first, they
could prevent other messages to get through entirely.
there is no real reason to handle invalidate messages first because
the other messages are very uncommon and won't interfer with
updates.
Change-Id: Ib95cdf35a91407bd2f4d69dd082c5f546e1e0071
Merge commit 'a7c76d8307a3b49bf5b8fdda3543455b0e5dd64c' into gingerbread-plus-aosp
* commit 'a7c76d8307a3b49bf5b8fdda3543455b0e5dd64c':
fix a bug where timeouts would only be handled when a message was delivered
the core screenshot function now can capture the screen at any lower resolution
performing bilinear filtering.
we also now have some client code to interface with the screenshot service.
it's now possible to request a screenshot at a lower resolution.
Change-Id: I33689bba98507ab928d0898b21596d0d2fe4b953
the core screenshot function now can capture the screen at any lower resolution
performing bilinear filtering.
we also now have some client code to interface with the screenshot service.
it's now possible to request a screenshot at a lower resolution.
Change-Id: I5a3b0e431421800e3aad601d9af8f94adffbc71f
Merge commit '495ad4f22096aa172d025c16c25497e7dad8f2bd'
* commit '495ad4f22096aa172d025c16c25497e7dad8f2bd':
simple test app for screen capture API
add support for [1974164] Be able to take a screen shot on the device
Merge commit 'beabe75a842d521b005999460d3a6361ab32108e' into gingerbread-plus-aosp
* commit 'beabe75a842d521b005999460d3a6361ab32108e':
simple test app for screen capture API
add support for [1974164] Be able to take a screen shot on the device
screenshots are taken using ISurfaceComposer::captureScreen() which returns
the size of the screenshot and an IMemoryHeap containing the data.
screenshots have limitations:
- they will always fail if a secure window is up on screen
- require GL_OES_framebuffer_object extension
- in some situation, video planes won't been captured
Change-Id: I741c68a2d2984fb139039301c3349e6780e2cd58
to DISABLE the h/w composer:
adb shell service call SurfaceFlinger 1008 i32 1
to ENABLE the h/w composer:
adb shell service call SurfaceFlinger 1008 i32 0
the state is dumped in "dumpsys SurfaceFlinger"
Change-Id: I23e2242d42c6e3fd5261a83332dd900b189e38ce
The bug caused SurfaceFlinger to constantly trigger reallocation of buffers
that requested a fixed size.
Change-Id: Ic993a60e6474e36a344c8b48d541a0d08b8c4faf
Add correct enumerants for OES_EGL_image_external to glext.h.
SurfaceFlinger now checks for the correct extension name.
Change-Id: I2ba2728a01fa2260bd086d2df4316c68f694a9b1
Merge commit 'b3ffc78f3432344702e6f5232067ab624083cad2' into gingerbread-plus-aosp
* commit 'b3ffc78f3432344702e6f5232067ab624083cad2':
Add logging of various important graphics events
There are 16 events logged in the event log:
SF_APP_DEQUEUE_BEFORE
SF_APP_DEQUEUE_AFTER
SF_APP_LOCK_BEFORE
SF_APP_LOCK_AFTER
SF_APP_QUEUE
SF_REPAINT
SF_COMPOSITION_COMPLETE
SF_UNLOCK_CLIENTS
SF_SWAP_BUFFERS
SF_REPAINT_DONE
SF_FB_POST_BEFORE
SF_FB_POST_AFTER
SF_FB_DEQUEUE_BEFORE
SF_FB_DEQUEUE_AFTER
SF_FB_LOCK_BEFORE
SF_FB_LOCK_AFTER
all events log the buffer conserned and a timestamp in microseconds.
by default the logging is not enabled, to turn it on:
adb shell service call SurfaceFlinger 1006 i31 1
adb shell setprop debug.graphic_log 1
The effect is immediate in SurfaceFlinger, but applications need to be
restarted.
Change-Id: Ifc2e31f7aed072d9a7dede20ff2ce59231edbec1
Merge commit '468204124e95bbf74ae8cc000318ade29e311be6'
* commit '468204124e95bbf74ae8cc000318ade29e311be6':
don't try to lock a buffer that wasn't allocated with SW usage bits
Merge commit '8eb16af29303cda190133a1d220b9ecd9341e261' into gingerbread-plus-aosp
* commit '8eb16af29303cda190133a1d220b9ecd9341e261':
don't try to lock a buffer that wasn't allocated with SW usage bits
Merge commit 'bc4389edfbb5777aec1a9af7863b2ca3ade2fa64'
* commit 'bc4389edfbb5777aec1a9af7863b2ca3ade2fa64':
fix [2931513] Add support for setting the orientation of an ANativeWindow
Merge commit '8395b4625b96f2133e2e4f595fdc69fbe222e4fc' into gingerbread-plus-aosp
* commit '8395b4625b96f2133e2e4f595fdc69fbe222e4fc':
fix [2931513] Add support for setting the orientation of an ANativeWindow
This change makes the camera HAL interface take an ANativeWindow interface from
which all the camera preview buffers will be allocated. The framework code
running in application processes now passes a Surface object rather than an
ISurface to the camera server via Binder when setting the preview surface. The
camera server then forwards that Surface object (which implements the
ANativeWindow interface) to the camera HAL, which uses it to communicate with
SurfaceFlinger to allocate the camera preview buffers.
Change-Id: Ie438f721559cd7de5e4f848a26d96360dda07b5f
commit 35cc68814a9537c31fde146e171e7b0bbdfe211e
Author: Andreas Huber <andih@google.com>
Date: Mon Aug 16 08:48:42 2010 -0700
Only enable support for yuv to yuv conversion on passion, where it's available, use the slower yuv->rgb565 path everywhere else.
commit d8ac5a8814103e60d11d2acf61997fc31a1dc58d
Author: Andreas Huber <andih@google.com>
Date: Fri Aug 13 13:56:44 2010 -0700
The software renderer takes over all rendering, converting from yuv to yuv if possible and rgb565 otherwise.
commit 684972074b74318bdcb826ed9b5b0864d2d2e273
Author: Andreas Huber <andih@google.com>
Date: Fri Aug 13 09:34:35 2010 -0700
A first shot at supporting the new rendering APIs.
Change-Id: Iea9b32856da46950501f1a700f616b5feac710fd
Merge commit '26bcc7b44238ea54105ef5a6020fa5c37bb33f03' into gingerbread-plus-aosp
* commit '26bcc7b44238ea54105ef5a6020fa5c37bb33f03':
revert hwcomposer HAL changes. DO NOT MERGE.
Merge commit '6a73368be44f45a80cc4b65dc57b9ff529cb2d89' into gingerbread-plus-aosp
* commit '6a73368be44f45a80cc4b65dc57b9ff529cb2d89':
fix a typo that prevented glTexImage2D codepath to work
Merge commit 'b7d1be01ae44428b947823fc48c1c126dcaa9732' into gingerbread-plus-aosp
* commit 'b7d1be01ae44428b947823fc48c1c126dcaa9732':
Fix a couple issues with the new hwcomposer HAL
- we now clear the framebuffer upon request from the HAL
- the HAL list size could get out of sync with reality
- there was also an issue where sometime we could run past the list
Change-Id: Ic3a34314aed24181f2d8cc787096af83c046ef27
Merge commit '90dc48b17f673b7e334e3254ea633450f994226c' into gingerbread-plus-aosp
* commit '90dc48b17f673b7e334e3254ea633450f994226c':
call into hwcomposer HAL when present
Merge commit '24d7050ca605804efd5fde03f0d0d8d1d052c247' into gingerbread-plus-aosp
* commit '24d7050ca605804efd5fde03f0d0d8d1d052c247':
don't handle the transparent region of a layer in draw()
Merge commit '8e7515d9c938f5addd08d97bccfccfa976e76c11' into gingerbread-plus-aosp
* commit '8e7515d9c938f5addd08d97bccfccfa976e76c11':
get rid of our LayerVector implementation
Merge commit '025822a03a09337ec382e708c5a798fe805109ed' into gingerbread-plus-aosp
* commit '025822a03a09337ec382e708c5a798fe805109ed':
keep a list of visible sorted surfaces
this is already taken into consideration in computeVisibleRegion
and therefore not needed at draw time.
Change-Id: I3fc7336d22f1147dfcd3a20fd71bf79b946d971f
Merge commit 'bc881e66d15181494fdd5d0ece83e20ef325453b' into gingerbread-plus-aosp
* commit 'bc881e66d15181494fdd5d0ece83e20ef325453b':
frameworks/base: Swap width and height of temporary buffer only with
orientation change
Current code swaps the width and height by assuming that aspect
ratio of the buffer width and height will be same as that of the
layout clip width and height. That is not always true.
Change the check to orientation change.
Change-Id: Ie387f3a7369025427484e4173cbde7a08df2b9d7
this situation happened when the last buffer needed to be resized
(or allocated, the first time). the assumption was that the buffer
was in use by SF itself as the current buffer (obviously, this
assumption made no sense when the buffer had never been allocated, btw).
the system would wait until some other buffer became the "front" buffer.
we fix this problem by entirely removing the requirement that the
buffer being resized cannot be the front buffer. instead, we just
allocate a new buffer and replace the front buffer by the new one.
the downside is that this uses more memory (an extra buffer) for a
brief amount of time while the old buffer is being reallocated and
before it has actually been replaced.
Change-Id: I022e4621209474ceb1c671b23deb4188eaaa7285
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Icd7336f7289db35df9c8c1857a5122bb8a6f1c86
moved surfaceflinger, audioflinger, cameraservice
all native services should now reside in this location.
Change-Id: Iee42b83dd2a94c3bf5107ab0895fe2dfcd5337a8
