Looks like a full GPU path is less efficient on some GPU
drivers that we're still using, and CPU is reliably faster...
(there's probably a locking condition going on somewhere, this
needs to be looked into)
Change-Id: I8878796a117d65bf2324507cf8755cadce49f6dc
Squashed commit of the following:
commit 012d3fe41d1d6cd38a0858b59145e9a4447641fa
Author: Hashcode <hashcode0f@gmail.com>
Date: Sun Dec 8 19:36:50 2013 +0000
sf: Always use opengles for screen capture
Go back to the usage of GRALLOC_USAGE_HW_TEXTURE and GRALLOC_USAGE_HW_RENDERER
in captureScreenImplLocked regardless of useReadPixels value
This fixes the EGL_NO_IMAGE_KHR error returned from
eglCreateImageKHR (blank images returned from screenshot path)
Change-Id: I62fe90a081607b9e89c67f3dcfd34c84efc89d35
commit 4866ddf98ac98d8e22a1cd6a21894bb17f274588
Author: Ricardo Cerqueira <cyanogenmod@cerqueira.org>
Date: Thu Oct 31 03:53:39 2013 +0000
Revert "remove support for glReadPixels screenshot path"
This reverts commit 3ca76f416b.
Conflicts:
include/gui/ISurfaceComposer.h
libs/gui/ISurfaceComposer.cpp
libs/gui/SurfaceComposerClient.cpp
services/surfaceflinger/SurfaceFlinger.cpp
services/surfaceflinger/SurfaceFlinger.h
Change-Id: I8c239e533757af770e418dbb198f5a86c736961f
Change-Id: I8c239e533757af770e418dbb198f5a86c736961f
This was originally added for b/14445579. An in-development app was
attempting to render to a window as an EGLSurface, then tear that
down, change some window properties, and create a new EGLSurface. The
second eglCreateWindowSurface failed because the window was already
connected. This change went in, but it turned out the real problem was
that the app still (unintentionally) had the surface current. After
the app bug was fixed, nobody revisited whether this change was
actually needed.
Turns out it wasn't needed. After an EGLSurface is both destroyed
*AND* not current (basically refcount==0), we were already
disconnecting the window in ~egl_surface_t().
Apart from being unnecessary and redundant, disconnecting the window
here is wrong for two reasons:
(a) The surface may still be in use after eglDestroySurface, if it was
still current. Rendering is undefined in that case, but disconnecting
the window leads to more catastrophic results than necessary.
(b) It's being called before calling the driver's eglDestroySurface.
The driver will almost definitely have a buffer dequeued that it needs
to cancel, and by disconnecting first we turn that into an error that
they don't have a graceful way to deal with.
Bug: 24524053
Change-Id: Ib063134413d25d3526f794aafb5e333e3417ea42
This change adds back the property overrides for several device
types as we had in CM 11.
It contains a squished commit of the following:
commit 5b9240927f8af0b26c406835df33b2d999496434
Author: Steve Kondik <shade@chemlab.org>
Date: Thu Nov 6 14:40:44 2014 -0800
Add hdpi-2048 tunings
commit ed579d8be17fb52ef92a1dc9c83843879f396fa1
Author: Steve Kondik <shade@chemlab.org>
Date: Sat Jan 4 12:12:00 2014 -0800
Update HWUI config for xxhdpi/2GB devices
commit 386f220e174f9ed5aad487867223033fd5d986c6
Author: Steve Kondik <shade@chemlab.org>
Date: Tue Aug 6 02:53:19 2013 -0700
hwui: Update configuration for 2GB/1080p devices
commit b7392d113d8ae6c3c07990bbb3f2621bef490d11
Author: Steve Kondik <shade@chemlab.org>
Date: Sat Jun 1 14:51:17 2013 +0200
provide overrides for hwui memory limits for xxhdpi phones
commit 247b3c635b1d6776ffedf3cd61a936546c2f6603
Author: Steve Kondik <shade@chemlab.org>
Date: Fri May 17 13:10:19 2013 -0700
Add heap configuration for 1080p phones with 2048m
* Increase heap start size to 16m to minimize GC with larger bitmaps
commit 9856e93970fd6def1349e564f17d42f505904eba
Author: Andrew Bartholomew <andrewb03@gmail.com>
Date: Thu Apr 25 13:48:21 2013 -0400
build/phone-xhdpi-1024-dalvik-heap.mk Revert AOSP heapgrowthlimit change from 64 to 96
This reverts part of AOSP change at
https://android.googlesource.com/platform/frameworks/native/+/c84e9844d621223d14178be521
Possible performance issues have arisen because of it. Discussion at
http://code.google.com/p/android/issues/detail?id=40961
Patch Set 2: Clean up commit message
commit bd7fb4be323f6f868a886b22e93cf203944af9a6
Author: Bhargav Upperla <bhargavuln@codeaurora.org>
Date: Thu May 23 12:50:15 2013 -0700
Configure dalvik heap parameters for low memory devices
Reduces after boot memory footprint by about 5-8MB
Note: This is for low memory based devices only (~512MB RAM
or less)
Change-Id: Id7e1967d18227359ad9631139bfd47e61e494829
This change is porting of following commits related to MDP3
1) SurfaceFlinger: Change to support framebuffer flip for 2D blitters
- Surfaceflinger does not flip framebuffers when there are
no layers marked for HWC_FRAMEBUFFER
- This change checks for the HWC_BLIT flag and will request a flip
to a new FB_TARGET buffer even if there are no FRAMEBUFFER layers
"Change-Id: I1cb44389a05c9ec049d7f0d39c288feccb11a91c"
2) SF: Avoid wormhole clear for BLIT calls
- Do not call GPU clear from SF when composition
type is BLIT as it'll be taken care in HAL.
"Change-Id: Ia613eb9b824c6484ecc8c8fa4ee883545d8541b8"
3) surfaceflinger: Allow gpu to render widevine level3
- Allow gpu to render widevine level3 but keep
blocking screen shots.
"Change-Id: I914232a062acbb7b17901dbf2b414973230e59d9"
Change-Id: I35eef9eb1597af21c195e07d5fe4c0c73ab3a269
Avoid disabling DispSync resync if app and SF events aren't
using phase offsets. This prevents hardware VSYNC from turning
on always whenever something needs to be drawn, thereby
bringing down the power numbers.
Change-Id: I83c8f79eb46b9fdaa730ec32767ebed3286347b8
- Set dim layer flag = 0x80000000 to send dim layer hint to HWC.
- Clear HWC_SKIP_LAYER flag when dim layer flag is set.
Change-Id: I56904c65fb487e6e89d4c057015443730d727299
Inside Surface::lock if new buffer is allocated
and DirtyRegion does not cover complete buffer
bounds then copyback may not cover all remaining area
as it copyback only area covered by dirty regions
from other buffers. This will lead to left out
black area which may cause flicker.
Change-Id: I4a3f7a56fc5fbaf4af926584919577d8d34bed57
Copyback dirty region logic does copyback,
even when its not necessary causing 2ms delay.
Fix the logic to copy back only what is necessary
CRs-fixed: 562334
Change-Id: I52de68258ac9f87d704ee5401f93417805fa6773
Author: Prabhanjan Kandula<pkandula@codeaurora.org>
SF: Add support for inverse mounted panels.
Add 180 rotation in SF to account for inverse mounted panels.
The framework will be unaffected and use policies for a 0 mounted
panel. SF changes the global transform and silently induces the H,V
flips. Similar flips are added to screenshots as well.
CRs-Fixed: 894147
Change-Id: I6e9576ee734ee85097491eaa1e8e94cfb3731e0f
Author: Ramkumar Radhakrishnan<ramkumar@codeaurora.org>
SF: Clear visible region of layer appropriately.
Clear visible region of layer having layer stack id different than
the display layer stack id to ensure that the layer won't be present
on the wrong display layer list.
Change-Id: I59289fea63ec7a2451d4715cfe7926ba34fdb8e3
Change-Id: I5ad08a6013aa173d621ee80c766a6e19e1086a35
Add definition of Tertiary display into the enumeration list of
surface composer header file, to support third display for all
Surface Flinger APIs.
Change-Id: Ic932be4f7f1ac9c44a5a8f36d17eb9386135de87
Add DisplayUtils class which uses the custom implementations
of ExLayer, ExSurfaceFlinger, ExHWComposer,
and ExVirtualDisplaySurface classes if needed
Change-Id: Ibdd8da5d3d0d602f42b76a15d0994c6aa98bee3f
This includes the following two changes squashed into one and
retaining the change I182f41edbaf9226fc62d6d17ee964998cd9f21f7
sf: Fixes for resolution change in SurfaceFlinger
1. Use active config from HWC when querying display attributes
When we query the display attributes we should use the active
config as reported by HWC in cases where HWC version is 1.4.
In all other cases we should revert to the default config,
config 0, as the active config.
2. Set/update the display config if HWC config change was successful
The new config should only be applied if HWC succeeded in changing
the active config. This would otherwise cause failure or undefined
behavior if the client sets an invalid/unsupported display config.
3. Set the active config at display creation time
When a new display device is added update the active config by
querying HWC.
Change-Id: I182f41edbaf9226fc62d6d17ee964998cd9f21f7
sf: Initialize active config for non-virtual displays at boot time
When a non-virtual display device is added at boot time, update the
active config by querying HWC otherwise the default config (config 0)
will be used.
Change-Id: I90f42fa1d20ed6176c4be464a10ae69a2f6a6d55
Change-Id: I182f41edbaf9226fc62d6d17ee964998cd9f21f7
In very low framerate situations, extrapolation is generally going to
either cause no benefit or make a mistake. We can safely turn it off
with no user-visible negative impact.
BUG=https://buganizer.corp.google.com/u/0/issues/24550942
TEST=Scrolled very slowly and saw mispredictions on Angler. With change,
saw the log message that the mispredictions were suppressed.
Change-Id: Ic9747d3ff098d7918047ada2ed1c2d21282c65b0
Add handling of "replacement" key events in InputReader and EventHub by
consulting device's character key map (if exists) for presence of
replacement key code for given get code and meta state combination,
before passing it to InputDispatcher.
This enables defining special keys, such as ESC, on keyboards lacking
enough physical keys, via combination of normal keys and modifiers, for
example AltR + 1 => ESC.
Bug: 24504154
Change-Id: I7e36104808bedcf724436c1fbb63d37c35cca8af
Currently keyboard maps allow to assign character sequences to key
events and allow specifying a so-called "fallback" key events that are
re-injected into input stream if target application indicates that it
was not able to handle the original key event. Unfortunately there is no
way to perform substitution before handing the event to applicationis.
This change adds a new keymap keyword "replace" that allows users query
"replacement" actions for key (if any), with the intent that such
replacement happens early in the event handling process.
Bug: 24504154
Change-Id: I3e6a2476c856524171df00ad22ff56f2018c1278
The uninitialized local variables pick up
whatever the memory content was there on stack.
This data gets sent to the remote process in
case of a failed transaction, which is a security
issue. Fixed.
(Partial manual merge of master change
12ba0f57d028a9c8f4eb3afddc326b70677d1e0c. Rest
to automerge from klp-dev)
For b/23696300
Change-Id: I704c9fab327b3545c58e8a9a96ac542eb7469c2a
Do not fall back to dalvik.vm.dex2oat-threads if
dalvik.vm.boot-dex2oat-threads is not set. Also do not ever use
the value of dalvik.vm.image-dex2oat-threads. Instead use the
default behavior of dex2oat in that situation.
(cherry picked from commit 919461cbeef3e9f35388fc099a5fcdae1cb79cc6)
Bug: 24413760
Change-Id: I42e60996341414b95b8df2d243d5e07f7f5ff9b6
