* The visible pointer icon when hovering or drawing with the stylus is
quite annoying when trying to actually draw with it. Turn it off by
default and add an option to turn it on.
Forward Port from CM-11.0
Change-Id: Ie4e9e6bcc48803b195d1615d83d6e36d663cc33a
When measuring GL latency with dumpsys, it's possible to hit a
race condition if the hardware is fast enough to complete rendering
the test cycle before the latency dump is requested, since it only
matches the latency for live layers (unless it's an animation. See
change I8bded1ea08a4cddefef0aa955401052bb9107c90)
So always save a reference to the last rendered SurfaceView frame,
and dump its values if there isn't an active one.
Change-Id: I740e9830161396ea955b5a53322bd8576b5136bc
Android 5.0 cannot form multitouch events from multiple input
devices. So it is not possible to report one touchpoint from the
stylus position and, at the same time, another touchpoint from a
finger touch. Instead, when a new input device starts up the currently
active input is cancelled. This is highly undesirable while writing
with the pen.
The easiest solution is to ignore non-stylus touch events while the
stylus is within range (hovering) of the touchscreen. For example,
N-trig digitizers implement this in hardware. But wacom digitizers do
report pen data simultaneously with touch data. This patch disables
(non-stylus) touch input within 50ms of stylus data. On my Galaxy
Note this is necessary to make stylus input usable.
Original commit by vbraun:
b9cb296130
Change-Id: I97f26369826e96c97461c8ae188f1c64dec1b4d3
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
Naveen Leekha