The matrix rotation params around the 2nd axis was not set correctly:
Initial matrix for axis 2 (green):
cos 0 sin 0 0
0 1 0 0 0
-sin 0 0 0 0
0 0 cos 1 0
After correction:
cos 0 -sin 0 0
0 1 0 0 0
sin 0 cos 0 0
0 0 0 1 0
Skia will clamp the radius independently in X and Y to ensure it is not larger than 1/2 the width (or height).
If the caller to our drawable gives us a single value, we'll assume they want it to be circular, and not an oval.
To do that, we clamp it up front, so we get (possibly smaller) circular corners, rather than potentially
elliptical ones.
This makes the progress bar look "nicer" when it is very thin in one dimension.
Adds a mechanism to tell Paint the scaling factor its target
canvas will have, for it to compute font metrics based on the
correct font size. Only TextView uses this, but that is enough
for the large majority of apps.
Change-Id: I6cacaa0dd26d40ee3ad959bed0028678d6e9016e
Ummmm... this turns out to be pretty bad. NinePatchDrawable was not
scaling its reported padding for compatibility mode, causing spacing
to be off. All over the place. This change should improve things quite
a bit (and magically makes nearly all of the menu flaws go away).
Change-Id: I94a8310d95b908b6f087db97d9afaed654ca6de5
Now that we are using preloaded drawables in compatibilty mode, when
constructing them from their constant state we need to set the new
drawable's target density appropriately.
Change-Id: I3665cbea09d38b9ac5f45f8c380dc8641f86b266
Remove the stuff that doesn't use preloaded drawables when in
compatibility mode, since this works fine ever since we were able
to deal with drawables in a different density than the canvas.
Change the snapshot function on View to return a snapshot at
the same size that will actually be drawn on screen (when in
compatibility mode), to be able to show scaling artifacts and
all.
This change was original an attempt to fix issue #2101917: Text
field edges appears to be improperly rounded. That turns out to
probably be something deeper in the graphics system, but also
included here is the debugging code I did to try to track down the
problem to make it easy to turn on again later.
Change-Id: I34bfca629639c7ff103f3989d88874112ef778d9
add documentation to notify developers about variable
camera specifications and add some more links
Change-Id: I46ef9811af17858cbc6547f88e626becb481b043
We currently allow the dither="true" flag to be set on
individual <bitmap> and <nine-patch> objects, but that flag
is overridden when they are included in a <selector>. This
change adds the dither="true" flag to StateListDrawable so
they can be dithered when desired.
Fixes http://b/issue?id=2068024
- Do better about figuring out when to stop them and other related window
management.
- Fix problem where we were not redrawing the surface when the orientation
changed. This was the cause of the device hang.
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.
Merge commit 'ef9fd18d90829ecbd37769cc05a8d5288aff821c'
* commit 'ef9fd18d90829ecbd37769cc05a8d5288aff821c':
Fiddle with default densities to try to sanitize the API.
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.
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
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.
Merge commit '59c25cbaf0dd690e503b881392510127441d9074'
* commit '59c25cbaf0dd690e503b881392510127441d9074':
DrawableContainer was not respecting the value returned by Drawable.getPadding(Rect).
Before this change, DrawableContainer would always return true from getPadding(Rect)
even if all of its children were returning false from getPadding(Rect). This change
modifies this behavior to respect getPadding(Rect): mConstantPadding is kept null
when getPadding(Rect) returns false for all of the children and a flag is set
to avoid recomputing that value every time getConstantPadding() is invoked.
