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
Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.
Change-Id: Iad05f5f6cca0f8b465dccd962b501dc18fe6e053
Clicking on a node in hierarchyviewer1 and hierarchyviewer2 and then
clicking the new "Dump DisplayList" button will cause the display
list for the selected node (including its children) to be output into
logcat.
Change-Id: Id32f62569ad1ab4d533bc62987f3a7390c1bb4e6
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
All accelerated lines are now rendered as quads. Hairlines used to
be rendered as GL_LINES, but these lines don't render the same as our
non-accelerated lines, so we're using quads for everything. Also, fixed
a bug in the way that we were offsetting quads (and not offseting points)
to ensure that our lines/points actuall start on the same pixels as
Skia's.
Change-Id: I51b923cc08a9858444c430ba07bc8aa0c83cbe6a
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
Bug #3409580
This bug affects anything that draws a 9patch inside a layer, this includes
launcher's workspace, all of the fade animations, etc.
Change-Id: Icbe8ecd158e3d5f44d07516462de68c5d1fb0a8f
Bug #3413433
This helps Launcher when a widget updates during a scroll, or when interacting
with widgets on the workspace if layers are still turned on.
Change-Id: Ic7a42eb34f74f4ae988039754f815e2efd1d1e4f
Bug #3385247
- The layer's alpha was interpreted in the wrong range 0..255 instead of 0..1
- 9-patches would not correctly dirty the layer region, the generated mesh
was incorrect
Change-Id: I4916249bedcdb0794929f3796bd17854971efc88
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
