Bug #5553515
The People app is forcing ACTV to show the IME which had the side effect
of showing the drop down popup. ACTV was unfortunately not ready to show
the drop down if the filtering resulted in no results. Doing so was putting
ACTV in a weird state that in turn caused a window to be leaked and really
bad behavior to occur in the lower graphics levels.
Change-Id: I2ff146d5ae4e4a28edf6ea17039c9f8fdb710e4f
This adds basic support for clip regions. It is currently disabled at compile
time. Enabling clip regions will require setting up a stencil buffer.
Change-Id: I638616a972276e38737f8ac0633692c3845eaa74
The render threat is likely to break your application if you initiate it.
As such it must be explicitely requested using the following meta-data
tag in your manifest's application tag:
<meta-data android:name="android.graphics.renderThread" android:value="true" />
Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
This could cause the draw() code of views to be invoked too often
or worse, called with the wrong canvas. For instance, a view backed
by a software layer could get its draw() method called to record a
display list. Using a software layer is the recommended way to use
drawing operations not supported in hardware. Since we would
sometimes call the draw() method with the hardware backend anyway,
the app could crash by executing an unsupported operation.
Change-Id: Ib5f9a3a4c6f3efff5e0162ecd73d2dffe06e30a6
If returns true, the SurfaceTexture will be released by TextureView.
If returns false, the client needs to release the SurfaceTexture.
Change-Id: I946f71e337ad4170c168854ac27e028b82489c8c
To profile the looper, run the following command:
adb shell am profile looper start <process> <file>
adb shell am profile looper stop <process>
Change-Id: I781f156e473d7bdbb6d13aaffeeaae88bc01a69f
This method is invoked by TextureView.getBitmap() and failures must be
caught to avoid leaving the GL context in a potentially bad state.
Change-Id: I620de395ba1bc20154de58c81963223dc55cac78
This is needed for Renderscript and it also makes implementations
of TextureView cleaner. This change also hooks up the onSurfaceTextureSizeCHanged()
callback whenever the view size changes.
Change-Id: I2f972ee4504d800329defefacf32cf20547d31a3
The previous implementation was using glBlendFunc with the parameters
GL_ZERO/GL_ZERO which doesn't work for text, paths and other alpha
sources (anti-aliasing.) The correct implementation is GL_ZERO/
GL_ONE_MINUS_SRC_ALPHA.
Change-Id: I4cca65e57b6a37bbf5a41d382cb0648ee8e11e79
Previously, the translucent boundary of AA lines would be scaled
by the line's transform. It should always be exactly one pixel wide
in screen space. This fix accounts for scaling for the boundary
region, and fixes some AA calculations that make wide/AA lines
more correct.
Change-Id: I30df2d5d96315bf3e7ff30be9735282fd5439a39
Bug #4343984
TextureView can be used to render media content (video, OpenGL,
RenderScript) inside a View.
The key difference with SurfaceView is that TextureView does
not create a new Surface. This gives the ability to seamlessly
transform, animate, fade, etc. a TextureView, which was hard
if not impossible to do with a SurfaceView.
A TextureView also interacts perfectly with ScrollView,
ListView, etc. It allows application to embed media content
in a much more flexible way than before.
For instance, to render the camera preview at 50% opacity,
all you need to do is the following:
mTextureView.setAlpha(0.5f);
Camera c = Camera.open();
c.setPreviewTexture(mTextureView.getSurfaceTexture());
c.startPreview();
TextureView uses a SurfaceTexture to get the job done. More
APIs are required to make it easy to create OpenGL contexts
for a TextureView. It can currently be done with a bit of
JNI code.
Change-Id: Iaa7953097ab5beb8437bcbbfa03b2df5b7f80cd7
