The makefile variable USE_OPENGL_RENDERER must be set to true to compile
libhwui and the related code in the JNI layer.
This change also removes obsolete APIs from Canvas that must not be used
and would be confusing if left in. These APIs were remnants of our first
attempt at an OpenGL renderer for the view hierarchy and had not been
taken out before Android 1.0 was released.
Change-Id: I2475ff1307212bab26c926724f3c508681c7dae1
Editable TextView now display a cursor controller under the insertion
point so that it can be precisely moved.
Change-Id: Ia2e6ddc57d249647ff6683e10e4226db3df27223
This change only adds the necessary API and stubs. The implementation
will be added in another change.
Change-Id: Ie50b8aff5868e78796cee331df15bdbf990d2ea1
The OpenGL ES 2.0 renderer can now draw colored rectangles. At least there's
something on screen now.
Change-Id: I80a13ccc1dd56784edf74f2670a364f30700234a
Add internal API (getTextRunAdvances) to Paint, use when measuring.
Add internal API (getTextRunCursor) to Paint, use when determining
valid cursor positions.
Remove java-level shaping code. Remove 'prep' code in TextLine
(except for replacement text) since shaping now is done on the fly as
needed in native.
Provide explicit shaping context bounds to internal text measuring,
cursor movement, and rendering APIs.
Update for to changes in external API in ushape.h.
Change-Id: I146958b624802ce8553125e5c3c6c03031bc9608
The range-check in drawVertices previously checked that the color
count was equal to the vertex count. However, the vertex count is
specified in array elements, and there's two array elements per
vertex for the positions, but only one array element per vertex
for the colors.
Correct the code so the check is consistent with the element count.
Change-Id: Id043f1003f9245f18adc91bac49dc33727ca765e
Adds drawTextRun as internal API on Canvas and GraphicsOperations.
Adds implementation to implementors of GraphicsOperations.
Adds state and API on Paint to control the bidi algorithm when used
by Canvas. This API is currently hidden.
The drawText changes are incomplete since shaping is not yet available
in the native code.
Change-Id: I4368048aef9545df0953a349381771603e04b619
It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
An issue with the density API is that bitmaps assumed the old default density,
so new programs would have to explicitly set the correct density for every bitmap
they create.
This is an attempt to fix that situation, by define the default density of bitmaps
to be the main screen's density, except for old apps where it is the original default
density.
Actually implementing this is not so great, though, because the Bitmap constructors
can't really know anything about who is calling them to know which density to use.
So at this level the compatibility mode is defined per-process -- meaning the initial
package loaded into a process defines the default bitmap density, and everyone else
loaded in later on has to live with that.
In practice this shouldn't be much of a problem, there shouldn't be much mixing of
old vs. new apps in a process. It does mean that, going forward, if a developer is
going to use shared user IDs for this, they will need to make sure either that all of
their apps are in the same compatibility mode, or that their code explicitly sets the
density of bitmaps it receives. This isn't all that great, but I think it is worth
the benefit of allowing people who write modern apps to not have to deal with bitmap
densities.
This change also does some cleanup of the density management (making sure to always
copy over bitmap densities, etc) and adds java docs to explain the various ways
density is set and used by the system.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
before the native canvas instance was created.
If the canvas constructors throw an exception (because the bitmap passed in is
immutable or already recycled), the constructor terminates early without
allocating the native canvas instance. For the most part, that's okay, since
the Canvas instance will never be returned to the application. However, the GC
will still call finalize() on the half-initialized Canvas.
The native methods for Canvas all assume that the canvas pointer passed down is
not null.
