mDrawingState doesn't need to be accessed by the
mStateLock, because by definition it's only accessed
from the main thread.
Similarily, the list of layers in the drawing state
cannot change (ie: is const).
Change-Id: I2e5da7f4d8caee7af7802b432cd45cc81c7c08b0
mFormat is not initialized with any value in Layer constructor, causing
a call to requestFormat() with no explicit format specified to fallback to
some uninitialized value. Such invalid path actually detected by valgrind.
Change-Id: Ib7faabcd61eaa26fb0ae7a9a486d9e258ba31b63
This change makes SurfaceFlinger treat layers for which the active
buffer has the GRALLOC_USAGE_PROTECTED bit set as if they have the
'secure' flag set.
Change-Id: Ic60b6513a63e4bb92ec6ce9fd12fd39b4ba5f674
Bug: 4081304
6d0f6cb Revert "Fix [3513017] in lockscreen but showing empty launcher (live wallpaper) only"
6154412 Revert "partially fix [3306150] HTML5 video with H/W acceleration blackout (DO NOT MERGE)"
37c2a37 fix [3408713] Dialog window invisible sometimes
It looks like there is a surface leak, it's unclear where it is.
Without those reverts, this would cause a leak of the associated buffers
which is far more problematic. this change might hide the surface leak.
Bug: 4078032
Change-Id: Iedcda3ffcdd2f69d41047b5c3134c1e867ff90d7
This change adds a new 'method' to the ANativeWindow interface to check
whether buffers queued to the window will be sent directly to the system
window compositor.
Change-Id: I4d4b199e328c110b68b250029aea650f03c8724d
Bug: 3495535
37c2a37 fix [3408713] Dialog window invisible sometimes
d35c666 fix [3385504] Surface flinger hang when adding dim surface
1723b04 fix [3389263] OMX.Nvidia.h264.decode fails to shutdown
1b0114f fix a surface leak in SurfaceFlinger
Bug: 3513017
Change-Id: Ia13ed8c9cdcb1f484e177cdcaff687e7c88a10c3
When some Surfaces are overlapping and one of them changed to
transparent or opaque, the back Surfaces should appear or
disappear. This patch calls SurfaceFlinger::computeVisibleRegions()
to re-calculate region of each Surface to implement the behavior.
Change-Id: Iffb1caf1b4ce28dff252e114fe5b9b07d9c84a6f
SF kept a strong reference to ISurface until the
window manager removed the surface from the screen.
This fell appart when running standalone tests, that is
when the window manager wasn't involved.
When the window manager is around, it would clean-up surfaces
even when an application died.
with this change, SF is able to do its own cleanup without
relying on the window manager.
the change is very simple, we simply don't keep a reference
to ISurface and make sure no more than one of them can
be created.
Change-Id: I61f2d7473bf8d4aa651549a846c34cdbb0d0c85a
Check requested format for device-specific formats, and assume (as
documented in libhardware/include/hardware/hardware.h) this is opaque
layer so no blending is necessary.
Bug: 3215931
Change-Id: Ib4dff8060ac522d201ff1e74807ac340c17d3fa7
with this change DimLayers will behave just like any other layer,
in particular they'll respect the layer transformations.
Change-Id: Icb4a1275e8bca9e3deb5f57c9f9219aaa69f9877
We were still destroying an ANativeWindow's buffer pretty soon
after it was removed from the window manager. This time
we really wait for the ISurace to go away.
Change-Id: I329273fedaeef76ee92836f6180c2c3808389330
This changes the ANativeWindow API and the two implementations to reset
the window's crop rectangle to be uncropped when the window's buffer
geometry is changed.
Bug: 3359604
Change-Id: I64283dc8382ae687787ec0bebe6a5d5b4a0dcd6b
Generally we never want to lock a buffer for write access if it is at
the "head" on the surfaceflinger side. The only exception (1) is when
the buffer is not currently in use AND there is at least one queued
buffer -- in which case, SurfaceFlinger will never use said buffer
anymore, because on the next composition around, it will be able to
retire the first queued buffer.
The logic above relies on SurfaceFlinger always retiring
and locking a buffer before composition -- unfortunately this
didn't happen during a screenshot.
This could leave us in a situation where a buffer is locked by the
application for write, and used by SurfaceFlinger for texturing,
causing a hang.
Here, we fix this issue by never assuming the exception (1), it was
intended as an optimization allowing ANativeWindow::lockBuffer() to
return sooner and was justified when most of SF composition was
done in software. The actual buffer locking is now ensured by
gralloc. We could have handled screenshots in a similar way to
a regular composition, but it could have caused glitches on screen,
essentially, taking a screenshot could cause to skip a frame.
now that we removed the notion of a "inUse" buffer in surfaceflinger
a lot of code can be simplified / removed.
noteworthy, the whole concept of "unlockClient" wrt. "compositionComplete"
is also gone.
We used to guarantee that a layer in SurfaceFlinger would never be
destroyed before all references (to its ISurface) on the client
side would be released. At some point, this guarantee got
relaxed to allow to free gralloc resources sooner. This last
change was incorrect, because:
- in implementations with reference-counting the gralloc resources
wouldn't be released anyways, until all the mapping were gone
- in implementations without ref counting, the client side
would most likely crash or do something bad
- it also caused the SharedBufferStack slot to be reallocated
to another surface, which could be problematic if the client
continued to use the surface after the window manager destroyed it.
So, we essentially reinstate the guarantee that layers won't be
destroyed until after all references to their ISurface are
released.
NOTE: This doesn't entirely fix 3306150 because there is another
problem there where the Browser continues to use a surface after it
has been destroyed.
also improve SurfaceFlinger 'dumpsys' log
list the purgatory, which shows windows that have been closed,
but for which the client still has references.
we were not clearing the screen entirely, which caused garbage when
the screen wasn't entirely covered by windows.
Change-Id: Ia7aa13c36a8a314e0e8427d419b16b9aa2165ddf
we make sure to call compositionComplete after everytime we do
composition with the GPU (even for the screenshot case), which is
where the buffer locks are released.
Change-Id: I450430d1e4d1ee9ce1023970642378c42cdcfa4c
now that we removed the notion of a "inUse" buffer in surfaceflinger
a lot of code can be simplified / removed.
noteworthy, the whole concept of "unlockClient" wrt. "compositionComplete"
is also gone.
Change-Id: I210413d4c8c0998dae05c8620ebfc895d3e6233d
list the purgatory, which shows windows that have been closed,
but for which the client still has references.
Change-Id: I5168bb88cb328d5d77d71d0871deb9190f493126
We used to guarantee that a layer in SurfaceFlinger would never be
destroyed before all references (to its ISurface) on the client
side would be released. At some point, this guarantee got
relaxed to allow to free gralloc resources sooner. This last
change was incorrect, because:
- in implementations with reference-counting the gralloc resources
wouldn't be released anyways, until all the mapping were gone
- in implementations without ref counting, the client side
would most likely crash or do something bad
- it also caused the SharedBufferStack slot to be reallocated
to another surface, which could be problematic if the client
continued to use the surface after the window manager destroyed it.
So, we essentially reinstate the guarantee that layers won't be
destroyed until after all references to their ISurface are
released.
NOTE: This doesn't entirely fix 3306150 because there is another
problem there where the Browser continues to use a surface after it
has been destroyed.
Change-Id: I305c830dd722b30a6d53cbf3a9c714fd3cf7eb06
the crop as well as buffer orientation can change at every frame, when that happens
we need to reset the hwc HAL (ie: set the GEOMETRY_CHANGED flag).
currently we achieve this by taking the same code path than an actual geometry change
which is a bit more heavy than necessary.
Change-Id: I751f9ed1eeec0c27db7df2e77d5d17c6bcc17a24
This change fixes a horrible hack that I did to allow application
processes to create GraphicBuffer objects by making a binder call to
SurfaceFlinger. This change introduces a new binder interface
specifically for doing this, and does it in such a way that
SurfaceFlinger will maintain a reference to the buffers until the app is
done with them.
Change-Id: Icb240397c6c206d7f69124c1497a829f051cb49b
This change adds a new binder method to the ISurfaceComposer interface.
This IPC is intended to allow SurfaceFlinger clients to allocate gralloc
buffers using SurfaceFlinger as a proxy to gralloc.
Change-Id: Ide9fc283aec5da6268ba62cfed0c3319a50b640d
we were not clearing the screen entirely, which caused garbage when
the screen wasn't entirely covered by windows.
Change-Id: Ie9ab9b94eabfa6cafddf45bb14bc733bdc8d35c0
while we're waiting for the real fix in the gralloc/gpu driver,
this workaround should resolve the issue.
we make sure to call compositionComplete after everytime we do
composition with the GPU (even for the screenshot case), which is
where the buffer locks are released.
Change-Id: I3cb5ad67d48c81a23100172bab77e86a70e29152
if a surface's buffers are reallocated, the current active buffer will
end-up pointing on one of these until a new buffer is retired.
we're now keeping a reference to the actual buffer until we retire a
new one.
Change-Id: Ib1703947e7a0340694d846e0962576318863b935
there was an issue were in some situation SF would call prepare() on hwc
with a NULL handle and never call prepare again.
in this situation, we onw set the SKIP flag to make sure that hwc
won't process this layer and as soon as we receive our first buffer we
trigger a recompute of the visible regions which will end-up calling
prepare() again.
Change-Id: I6b400b2df79712408b9315a9859290c7fcb1609e
There was a leak of Surface tokens when a surface was detached from a UserClient.
We now always detach a surface from its client before attaching to the new one,
this guarantees that its token is freed.
Change-Id: Icfad0b16286ed58155bdfafdf36ab161440aa485
For multiple reason, this effect is not maintainable and was never
used due to its abysmal performance. it'll be resurected when it can be
implemented efficiently.
Change-Id: Id4222c9b86c629275cdec18873ef07be8723b6d2
* commit 'a2977c383d363e1e88a5b36230b1fa4c312807d2':
[3171580] SurfaceFlinger Bypass mode. (DO NOT MERGE)
[3171580] Add transform field to native buffers. (DO NOT MERGE)
* commit '05813b0eb92cb1bc79607ee402f14ca1e4b43f6d':
[3253328, 3171580] Treat GONE and INVISIBLE views the same when calculating transparent regions
[3171580] Fix two typos related to fixed-size buffers
This is a poor's man precursor to the h/w composer HAL.
Basically we detect when a window is full screen and in
that case we bypass surfaceflinger's composition step, which
yields to much improved performance.
Change-Id: Ie03796ae81a1c951949b771c9323044b980cb347
mFixedSize was never set, this bug was introduced during some "cleanup", in
practice this could cause some issues when a fixed-size buffer was used and
the window was resized.
Layer::drawForSreenShot() had a typo that had no effect.
mFixedSize was used to determine if filtering was needed, which was a bit too
conservative and created a dependency between filtering and "fixed size" states
which should exist.
Now we enable filtering based on the size of the buffer vs. the size of the layer.
Change-Id: I32044e91b0c944c1b137efdceb3f01dfaa78119d
some of these failures are not fatal and even expected in some cases
so they should not emit a dump in the log in those cases.
Change-Id: Idcfa252e3bfa9d74e27fe4ad8f8623aa01aa9c5e
This change removes an optimization from SurfaceFlinger that skipped
composition when it got window updates that had an empty dirty region.
This optimization caused problems because it would skip the hwcomposer
set call, which could leave the window's previous frame buffer bound to
an overlay plane. When the application subsequently dequeued and tried
to lock its next buffer (which would be the buffer currently bound to
the overlay), the lock call would block until the next hwcomposer set
call (which may never happen).
Change-Id: I563b626a1d52c1f30eb82489eae0ceb4edc79936
Bug: 3138752
Two bugs were counter acting each other.
- rotation matrices are on the left-hand side of multiplies
- the transform of the overlay is applied before that of the layer
Change-Id: Ia79bd368e9b719235c89ecf244ea263f01ce906a
Merge commit 'e1ca532d72cbfacdce794f8bb4d439e609ec9871'
* commit 'e1ca532d72cbfacdce794f8bb4d439e609ec9871':
fix [3123221] Video sticks playing back upside down following orientation switch
Merge commit 'b4645353090f1bdd5cc1d4ab98feac7ccf966368'
* commit 'b4645353090f1bdd5cc1d4ab98feac7ccf966368':
fix [3118445] Transform * Transform does not work as expected
Merge commit '457bed2bc6561dd67429dde238453fee8602fa9b' into gingerbread-plus-aosp
* commit '457bed2bc6561dd67429dde238453fee8602fa9b':
fix [3123221] Video sticks playing back upside down following orientation switch
Merge commit 'ce4d36ad729f83253d4c5ec9906148f45cc00f8e' into gingerbread-plus-aosp
* commit 'ce4d36ad729f83253d4c5ec9906148f45cc00f8e':
fix [3118445] Transform * Transform does not work as expected
the overlay wasn't reconfigured when the screen-orientation changed. It was
only done when a parameter of the surface itself changed.
Change-Id: I0ca0925bf58ded4c91ab89d12cb1fe4d1477c96c
The problem wasn't in the multiply operator, but rather in the code
that built the transform from the HAL bitmask.
We now use the multiply operator to build the Transform from the bitmask,
which guarantees, it'll always be correct.
Also added a simple test for Transform.
Change-Id: I09bf3b0e51d92f59d83ea91c4cc94fc2aa0bf227
Merge commit 'fb31036fd844444c395a2ae9c97439eec9f774e4'
* commit 'fb31036fd844444c395a2ae9c97439eec9f774e4':
Use the context_priority extension when present.
Merge commit '583fefc8dcadecc7fc933513d3569dd9c16c100c' into gingerbread-plus-aosp
* commit '583fefc8dcadecc7fc933513d3569dd9c16c100c':
Use the context_priority extension when present.
Merge commit '9f6d18cadf9ac50062063f5f5ff5de7f6895696a'
* commit '9f6d18cadf9ac50062063f5f5ff5de7f6895696a':
[3095807] screen takes a long time to turn on
Merge commit 'a8faf91fa558be1235d508e776eb24be4429585c'
* commit 'a8faf91fa558be1235d508e776eb24be4429585c':
fix [3095607] Gingerbread screen turn-on animation does not show the last frame
Merge commit '3d4a9774ced0c704da455c5bd9989127e90ba133'
* commit '3d4a9774ced0c704da455c5bd9989127e90ba133':
may fix 3097381 and 3097482. don't abort on/off if the animation fails
Merge commit '5bfa3a34eaef759c3ec4def76f646eb1c0bf997f'
* commit '5bfa3a34eaef759c3ec4def76f646eb1c0bf997f':
implement part of [3094280] New animation for screen on and screen off
Merge commit '043581382e43acbe29a8a62420bc765f49a9dd90' into gingerbread-plus-aosp
* commit '043581382e43acbe29a8a62420bc765f49a9dd90':
[3095807] screen takes a long time to turn on
Merge commit 'd4e03f37423bee383d17f7292753a5f67e497a28' into gingerbread-plus-aosp
* commit 'd4e03f37423bee383d17f7292753a5f67e497a28':
addresses parts of 3096779 and 3097475
Merge commit '6d71f6a0ae9fd81ce25562aee67f841b5d8394cf' into gingerbread-plus-aosp
* commit '6d71f6a0ae9fd81ce25562aee67f841b5d8394cf':
fix [3095607] Gingerbread screen turn-on animation does not show the last frame
3097475: Animation setting should control the screen on animation
3096779: CRT power-on animation can briefly show the top app instead of lockscreen
There is now a parameter that controls wether the ON and/or OFF animation are
performed. we also always clear the screen to black on power off, to make
sure it won't briefly appear on power on.
HOWEVER, 3096779 is not 100% fixed in the case where we're doing the animation
because there is a race, where SF doesn't wait (b/c it doesn't know) for the
framework to have redrawn the lockscreen.
Change-Id: Ie0f02c9225fcdf24b1e8907e268eb7da2c5b0a03
Merge commit 'b0e020ab409b725a556f2c5043b08c9bac2c29bf' into gingerbread-plus-aosp
* commit 'b0e020ab409b725a556f2c5043b08c9bac2c29bf':
may fix 3097381 and 3097482. don't abort on/off if the animation fails
always redraw the screen entirely after the power-on animation, because:
- the animation may not run (ie: on the emu)
- the animation may not contain the video planes
- the interpolation may not be perfect and not land exactly on the last frame
Change-Id: I9ba40f537b1e94464f8a3ed6f81e7c2f552df51d
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
