runRemainingAnimations is used to animate the available animation handle
which were not yet run, it actually animate those animation handle and
removes from the list by notifyAnimationsRan(). In case if these animation
handles are not removed, it leads to the Fatal Assert of runRemainingAnimations.
Some usecases causes the addition of animation handle when there is
no animators, in these cases this check prevents execution of
notifyAnimationsRan() leads to Fatal Assert crash of runRemainingAnimations.
Allowing the animation to happen irrespective of animators solves the problem.
Change-Id: Ifa72286cdc6ff785fcc999f3b951dd787e7003e9
OpenGL ES 3.0+ lets us specify the row length for unpack operations
such as glTexSubImage2D(). This allows us to upload a sub-rectangle
of a texture. Also, the GL_EXT_unpack_subimage extension can also
support this feature in OpenGL ES 2.0
Change-Id: Id43c2c55c5eaefbace67087c955f0b4324fb2c35
Signed-off-by: xiaozhengdong <xiaozhengdong@xiaomi.com>
Now that ZipFileRO::startIteration supports prefix/suffix matching,
we can pass dirName to the function for simpler code and slightly
better performance.
(cherry-pick of c796ad0a8be6df4a3b354690dfe5ce1df8136c09)
Change-Id: I0e2ac58de28020c2af8d8e569a97592b09596185
for better performance. Without the optimization, these two functions
may check more than 100k file names in the pre-installed APK files,
which can take a few seconds to finish even on a recent device.
(cherry-pick of 34fe3df8519523dbb4bc27010fa57f259d5e868d)
Bug: 21957428
Change-Id: I5ebe0438019958d883a7fda6bd92ea4484211d23
Due to precision loss of float math, we sometimes get 1.000001f for
dotProduct. This causes NaN result from acosf() and floor() funcs.
At the moment, this does not cause any problems on ARM, as casting
NaN to int results in 0. On mips however (possibly on x86), such cast
gives INT_MAX, so crash occurs when trying to use the resulting value.
Change-Id: I8e0285a0306a65b8469d9f4885c19665066fc4c8
getEntryInfo crashes on 64-bit devices because "long" types
were being passed int pointers (that pointed to a stack frame)
that were reinterpret_cast'ed to long* (sigh.). To fix this issue
once and for all, use types with explicitly defined widths.
This change also removes some dead invariant checking from
Asset.cpp instead of cleaning it up.
Note that we've introduced a wart in NativeLibraryHelper, where
we need to deal with zlib's uLong type, which is "at least 32 bits
wide".
bug: 21622286
(cherry picked from commit 4600dd053dbdbd4b95f3b11057a1cc55b99f9c77)
Change-Id: I7886cb37a229cc27c625699c80e6a6a6117d2203
glFinish() dequeues a native buffer, and it fails when
the bufeer has been abandoned, this is ok and will not
casue the app crash
GL_OUT_OF_MEMORY is generated in this case, and it is
not reset until glGetError called. This is happened in
build layer function, glGetError is called after glTexImg2d,
and get GL_OUT_OF_MEMORY, then this function return as OOM,
and app crash
Fix it by adding a glGetError after glFinish
Change-Id: I8803a726b6f609c4a2f8a6aa6bb7ff7064808932
Was here because UBsan found integer overflow in the parsing for hex
numbers, since hex numbers here are actually unsigned but assigned to
a signed integer.
Also fixes a number of missing error conditions.
Change-Id: Iaea576daedfc6c75521cde02de3fe9dd0198a3b7
To obtain the gfxinfo for each process, the static method of RenderProxy is used, which is named outputLogBuffer().
In there,
1. RenderTask is created for getting DisplayList Commands in RenderNode.
2. staticPostAndWait() is called
3. RenderThread's instance is created by 'RenderThread::getInstance()' in staticPostAndWait()
In case of the service, they don't use HW Acceleration, so don't need RenderThread.
But, by the process of No.3, RenderThread is created for all process.
As we know, RenderThread never be destroyed while the process is alive.
This patch checks RenderThread instance before the creation of RenderTask.
And, there is no one, just return to prevent the unnecessay creation of it.
Change-Id: I4fe29d83c9ced3e8b67177c0874c5d8ee62e1870
New ShadowTask with the ShadowDescription key that already
exists in the shadow LruCache will leak as it is not being
added.
Fix adds check for the existing key that is common in the hwui
code but missing for the TessellationCache::precacheShadow
function.
Change-Id: I37fd5ec82f8b8da5d1ec0f2ab9fd04c5f8534367
The base APK may have resources with configurations that compete
against some splits. The base APK must be involved in the selection
of splits.
Bug:18982001
Change-Id: Ieb29b5a36cf2c68e7831484d98a9fd275acd97e8
Most matrices used by the UI toolkit are translation matrices, whose
inverses can be quickly computed by using the negated translation
vector.
Change-Id: I54a28a634a586085779bfc26f3a4160cd5ab2b22
We'd observed a bug in which an unchanged file was nevertheless
being redundantly transmitted for backup on every backup pass.
The underlying issue turns out to have been the FileBackupHelper
base implementation's logic for diffing the prior-state file
set against the current state, in the case when there had been
deletions of prior files. In addition, there was also a
parallel bug in which file checksums were not calculated
properly in some cases, leading to at least one additional
redundant backup of the file in question.
Bug 18694053
Change-Id: Ie0dec06486b5fef4624561737019569c85d6b2a0
If hwuiTask thread is exited while HWUI renders something,
some tasks can remain unfinished forever.
This can make ANR problem if RenderThread waits this kind of tasks.
According to the current implementation, hwuiTask threads are
exited when HWUI receives trimMemory() callback with level >= 20
and some applications such as SystemUI can receive trimMemory()
with level >= 20 even though they renders something yet.
(For instance, when RecentsActivity in SystemUI is finished,
HWUI receives trimMemory() callback with level >= 20
but SystemUI should still render the status bar and navigation bar.)
This patch prevents the tasks from remaining unfinished and
make the tasks executed immediately if they cannot be added
to their TaskProcessors.
Change-Id: I5bd26439aa5f183b1a7c1ce466362e27554b4d16
Bug: 18226391
The issue occurs as a result of a dispatchFrame itself
taking longer than 12ms, the alloted budget. The result
is that a vsync request (which occured at the end) would
miss the vsync that occured 1ms prior to the end of the frame.
As a result it would end up waiting for the following vsync,
essentially dropping to 30fps even though 60 could have been
sustained.
Fix this with a few tweaks.
First, adjust the UI thread's delay bias from (now + 4ms) to
(vsync + 4ms), this prevents RT animators from slowly drifting
if the vsync occurs mid-task.
Second, request a vsync preemptively prior to running callbacks.
This way if any callbacks needs the next vsync and it takes
"too long", we will catch that vsync.
Finally, fix an issue where the display event queue was always
drained & rejected at the end of a task loop. Instead, drain
and reject all stale vsyncs. This still prevents the issue of
both UI thread & RT thread trying to drive 2 frames in a single
pulse, but also allows RT to notice that it missed a vsync
pulse it needed and that it should speed-up a bit in response
Change-Id: I9d6be037737e9283297898cac2e3563453e797cd
