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
Bug #4318323
This change also fixes the fact that shaders were not modulated
by the paint's color when drawing paths.
Change-Id: Id88804143aea06c895d4cbcdbe106d660230aa5a
Draw anti-aliased lines with OpenGL by constructing a quad with
a border that fades out (to mimic fragment coverage).
Change-Id: Ib81a3e62d663acdf1b46b401ac4aa7ee9855cc7e
There was a bug in the dirty region optimizations when
using alpha layers. This prevented translucent objects from
being drawn at all in many situations.
Change-Id: I23e9bce3595fbd6fe2bda15e8753a0f35baffb82
This brings back an optimization disabled in HC-MR1. This time the
correct geometry is generated to avoid unnecessary blending.
Change-Id: Id56404dc46bb84c75facc25c18488a690741b592
Bug #3515248
The problem is caused by the fast path when compositing layers on screen.
The fast path draws a single quad using glDrawArrays() whereas the general
path draws an arbitrary mesh using glDrawElements(). It looks like there's
an issue in the driver since glDrawArrays() is significantly slower than
glDrawElements() for a quad (6 vertices!)
This change just gets rid of the fast path.
Change-Id: Ib2361253ec67f44a988270f76c183422f12ce537
Bug #4093871
This bug was introduced by a change that modified the way fade areas
are cleared. The previous change relied on Rect::intersect() to empty
the intersected rect when the two rects don't intersect. Unfortunately
this is not what intersect() does. The fix is rather simple and
sets the layer's bounds to empty when they don't intersect with the
clip or the viewport. This has the side effect of ignoring the layer
which is the expected result.
Change-Id: Icf0038b9a476c53f8eff7084136aba3033d093e6
Bug #4092053
The problem always existed but was made visible by partial invalidation.
When saving a layer, the renderer would try to postpone glClear()
operations until the next drawing command. This however does not work
since the clip might have changed. The fix is rather simple and
simply gets rid of this "optimization" (that turned out to be
usless anyway given how View issues saveLayer() calls.)
This change also fixes an issue with gradients (color stops where
not properly computed when using a null stops array) and optimizes
display lists rendering (quickly rejects larger portions of the
tree to avoid executing unnecessary code.)
Change-Id: I0f5b5f6e1220d41a09cc2fa84c212b0b4afd9c46
Bug #3461349
This change also fixes two bugs that prevented partial invalidates
from working with other views. Both bugs were in our EGL implementation:
they were preventing the caller from comparing the current context/surface
with another context/surface. This was causing HardwareRenderer to always
redraw the entire screen.
Change-Id: I33e096b304d4a0b7e6c8f92930f71d2ece9bebf5
Bug #3431907
When drawing layers inside a layer, the wrong target FBO would be used.
This would happen for instance with app widgets using a ViewFlipper
in Launcher. The ViewFlipper uses a fade animation that triggers a
call to saveLayerAlpha(), which in turns creates an FBO. If this happened
during a scroll, the ViewFlipper's FBO would be composited back directly
inside FBO 0, i.e. the screen. This properly initializes the snapshots
of hardware layers to use the layer's FBO as the default compositing
target instead of using 0.
This problem did not happen when drawing hardware layers inside
hardware layers because LayerRenderer already takes care of figuring
out the FBO it needs to composite into. The bug would occur only
with layers generated with saveLayer() and its saveLayerAlpha()
variation.
Layers inside hardware layers insider layers inside hardware layers
now work properly.
Change-Id: Ibe852301087f3d414ad8a18436eebc81f8ac66f5
Glyphs drawn with paints that had different textScaleX values were not
being recognized as different, so the glyph cache was being used regardless
of different scaleX values. This change adds the scaleX attribute to the native
Font object to allow the cache to distinguish between this difference and cache
accordingly.
Change-Id: I5d8fc26d47460b27dc8e373a473d46b2f1b8dc30
- use GenerationCache for caching
- move GenerationCache.h from libs/hwui/utils to include/utils
- add #define for cache activation / deactivation
Change-Id: Ifaf519f0b5e33b087a453e4aa6430162d8438f20
