The fisheye effect generates a graphical artifact close to the center of
the picture, due to bad precision and division by zero in the shader.
The problem is fixed by making a small change in the shader, so that the
picture is uniformly scaled close to the center instead. This avoids the
problem and looks as expected, without affecting the performance.
Bug: 64107054
Test: Manual - Install dev sample HelloEffects and use the 'fisheye'
from the overflow. There is a small artifact in the center of the puppy
without this patch applied. Think of the puppies!!
Change-Id: I063f60facd30708db29ff544fdb47ac896e3d54b
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
(cherry picked from 6387604f9e672ece85e07c4bcbd7be396867f06f)
Bug: 30188076
Test: make checkbuild
Merged-In: I13e88297731253420e4e5f5291d503f13a39a156
Change-Id: I58446eb8c45d8ac2bcdbc9fa40d1321e811bdd4b
This was caught by clang's static analyzer. Warning:
frameworks/base/media/mca/filterfw/native/core/shader_program.cpp:1031:3:
warning: Potential leak of memory pointed to by 'attrib.owned_data'
return StoreAttribute(attrib);
Bug: None.
Test: The static analyzer no longer complains.
Change-Id: Ibef0368dfa48ba57e38019a5a3e33d5bacd847a2
This patch fixes multiple static analyzer warnings:
frameworks/base/media/mca/filterfw/jni/jni_gl_environment.cpp:66:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_native_frame.cpp:38:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_native_program.cpp:31:10:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_shader_program.cpp:50:12:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_shader_program.cpp:57:12:
warning: Potential memory leak
frameworks/base/media/mca/filterfw/jni/jni_vertex_frame.cpp:27:10:
warning: Potential memory leak
Note that the changes in jni_gl_frame are purely cosmetic; those aren't
fixing any warnings. I'm happy to back them out if anyone wants.
Bug: None.
Test: All of the static analyzer warnings mentioned above are now gone.
Change-Id: I49dc6d7c789233d6497f8bcc766ca66aec72b27b
http://b/28149048http://b/29823425
Disable -Wconstant-conversion that gets triggered in
native/imageproc/to_rgba.c.
Test: Tested build, boot and common usage for Arm, Arm64, x86, x86_64,
Mips images in AOSP and internal branch.
Change-Id: Ia8dbe49a1a8577599244642cbd2e3bb17ec1f83c
This library includes libmedia headers, and needs its full include path.
Bug: 27804373
Test: This code compiles with a slightly modified libmedia include
path.
Change-Id: Ic9253c0f0e7236435f36f2baf47411ca7db187cd
Adjust format strings to not produce Clang warnings in both 32-bit and
64-bit builds
Change-Id: I76c29d8d5d0fb4b5e9d9518077652370ffe9e871
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Some JNI functions ignore the JNI environment and class information, but
still take the parameters -- causing a build failure with clang (and gcc
with -Wextra enabled). Ignore this.
Change-Id: I049fcf65991b19d2416fce105699311803b43cfc
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Remove unused variables and static functions clang complains about,
disable warnings about unused parameters (needed for clang and for gcc
with -Wextra enabled)
Change-Id: I76a22cd0158b3c7375c54e3d4d15bc1ac448591e
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.
That said...
Math is faster than FloatMath with AOT compilation.
While making the change, occurances of:
{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))
have been replaced with:
{(float)} Math.hypot(x, y)
Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:
Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().
hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.
Different implementations measured on hammerhead / L:
AOT compiled:
[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials
[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials
[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials
[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials
[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials
[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials
Interpreter:
benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials
Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
Removes the dependency on default constructor parameters for
GLConsumer so that a different constructor prototype can safely be
added.
Change-Id: I0da924bbd4c141edbf305598c1be8bc575654680
For storing pointers, long is used in media classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Idc4ca0124d03df7f9cef412488abafd020e5e774
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
The C++ class names don't match what the classes do, so rename
ISurfaceTexture to IGraphicBufferProducer, and SurfaceTexture to
GLConsumer.
Bug 7736700
Change-Id: I08e677faf2ebb418ef131d0a8008e01037db0e50
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
If the filter graph in an app closes out, the SurfaceTextureTarget
filter was losing the reference to the original surfacetexture, and the
app would re-start the graph without setting the surfacetexture again,
thus leading to a crash in registering a surface from surfacetexture.
Typical scenarios is start/stop immediately in camera effects recording.
Fix part of b/6651352
Fix part of b/6655597
Change-Id: Ib2bae7e886784e91b3a886f7ccd439ff190feb22
