| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
bug:4303702
Change-Id: I31f8df1e24206ef6389f814d421a3fb84b1dc00f
|
|
|
|
|
| |
bug:4271501
Change-Id: I9836f2775b0acf89b09b6edf2111cd44f0d1daa8
|
|\ |
|
| |
| |
| |
| |
| |
| | |
bug:4181605 bug:3389597
Change-Id: I2717cdfdeea12df434a119bb8dcc9d2f17f07a7e
(cherry picked from commit 14866c7d6aaa0930627503d0b49bde8e21e90a6e)
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The computation for the invalidated / clipping rects were wrong,
sometimes causing the linked bug when layers had a transparent
background (they were not obeying the clipping rect passed by
the framework).
java counterpart CL:
https://android-git.corp.google.com/g/#change,105503
Change-Id: I60769e7cbf1a3a939724c57b3d3ce63a6f87aa87
|
|/
|
|
|
|
| |
Bug: 4262018
Change-Id: I0ddda2348e72484cd57fc1909efed47bf8e2222d
|
|\ |
|
| |
| |
| |
| |
| | |
bug:4232704
Change-Id: I64833baeab708fabe88873573235a896b86b6098
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Bug: 4232693
Change-Id: I273671aea3dc379858f11546e6459fd9e1443d4f
|
|\ \ \
| |/ /
|/| | |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of scaling the final rect to compare, scaling the dirtyrect.
Because the dirtyrect will be discarded anyway.
This can better preserve the precision the final rect.
bug:4186567
Change-Id: Icade7a0b1ff13cd36791c7a3c0e2d624870fb44a
|
|/
|
|
|
|
|
|
| |
Bug: 4184047
This is caused by textures being marked as unused by swapPages().
Limiting when swapPages() releases textures slightly fixes the issue.
Change-Id: I8ac94f1370b023355f4b6f5877c3929b5d6d3ef6
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This solves the problem on the nytimes.com/skimmer website.
We were applying the last animation step twice.
bug:4181605
Change-Id: Id2c003b5a2b6a8c56aa3d6be76d4a6cccfb86ad8
|
|/
|
|
|
|
|
|
|
| |
We marked layers dirty when they did not
have a texture -- even the layers that
did not *need* a texture...
bug:4195690
Change-Id: Ic2a0fdf9462277d060f07ef7d281f5d27e7e8ed5
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
if we're drawing a horizontal line, try using a bitmap-shader to simulate the
dash, as this can be much faster than the general SkDashPathEffect.
bug:4163023
Change-Id: I362543d6efb83ebf395cbe92c2d889c590a7c2df
|
| |
| |
| |
| |
| |
| |
| | |
Webkit.
bug: 4171470
Change-Id: I6afe957b2eccae249afa46baede822c34f8f1a7f
|
|/
|
|
|
|
|
|
|
|
| |
The bug caused a continuous redraw if you had a webview without content;
the Activity containing the webview would thus not be marked as idle.
The pagecycler is launching such an activity and wait until it's idle
to determinate that it's usable to loade urls...
bug:4172381
Change-Id: I6c838c5f6757186d01e8e476a8fc5101ea00ed15
|
|
|
|
|
|
|
|
| |
- don't queue large number of tiles when scrolling/zooming
- while scrolling/zooming, schedule the tiles generation at the front of the queue
bug:4136077
Change-Id: I652464d01f3000e88e42fad1e98402436a85dce4
|
|
|
|
|
| |
bug:4163243 bug:4163233 bug:4159272 bug:4159270 bug:3442104 bug:4163237
Change-Id: Iab71d1da3f0ca6c52b23ddfb8b86c58b118b60e0
|
|\
| |
| |
| | |
bug:3389597" into honeycomb-mr1
|
| |
| |
| |
| |
| |
| | |
Plus animations improvement bug:3389597
Change-Id: I07319910ae366d3e237bf3a1042cf28217434437
|
|/
|
|
|
| |
bug: 4165067
Change-Id: I2f50f600133300cec712b0177ead1a7afbbee2c3
|
|
|
|
|
|
|
|
|
| |
We were preventing the layers' positions to be updated
while waiting for the base surface to render.
This also fix some repainting issues.
bug:4136077
Change-Id: I6870faf8296e205c6ee58e80b1cf95833a67814b
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Bug: 4163023
Change-Id: Ie76a2f5855130ff174a80d1c7e9187bea89f3aa5
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Layer release textures (setting their owner to zero). Texture with no
owners are routinely destroyed by the TilesManager.
When a texture is busy, the release is delayed until the end of the
painting; if the owner of the texture is still the same, we then
remove it.
The problem was that a layer could release a busy texture, thereby
delaying the release; and in a next cycle re-acquire that same texture.
The delayed release would then kicks in, and proceed, as the owner
was still the same one as the one that originally asked for the release.
We would then have a situation where the layer thought it acquired a
texture, while that texture's owner was ultimately set to zero.
The TilesManager would then proceed to destroy that texture.
The next time the layer tried to use the texture, it would either crash
or more often block on acquiring a lock on it, causing an ANR.
bug:3472320
Change-Id: I84a064b1aa6636a18e0518e34c8572cbea3eb558
|
|\ |
|
| |
| |
| |
| |
| | |
bug:4129388
Change-Id: I52963d38412d0fd69c4695a281ad6558c27999ed
|
| |
| |
| |
| |
| |
| | |
bug:4142131
Change-Id: I871924cb7587077f50fdf4f9a00056f795a8daea
|
|/
|
|
|
|
|
| |
Don't save the extras in the picture when drawing.
bug:4126884 bug:4132721
Change-Id: I52c46a33f847e64c1f8245a0bb84445a948d72a4
|
|
|
|
|
|
|
| |
before locking a texture, it needs to be ready.
bug:4136077
Change-Id: Ib8235694e1a43524c52a02a5f288235d56088f46
|
|
|
|
|
| |
bug:4136077
Change-Id: I2dabdf612e29c4e4c9a0b744ddecaeda7a537ba5
|
|
|
|
|
| |
bug:4136077
Change-Id: Ia975ac78f724450be6f36a61316c872c4d88d7a0
|
|
|
|
|
|
|
| |
This improves performances by a visible factor on some websites.
bug:4124418
Change-Id: I9b24408b686e24cf323eb5bae977d74a0f2e2a34
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reworked the logic of setupForText() and setupShadowPaint() to render
correctly, as exhibited by http://acid3.acidtests.org.
Bug: 4075135
Change-Id: I595456b658d0872183dedcbc726be44783440f89
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The problem was that when attempting to forcefully destroy a texture
in TilesManager::cleanupLayersTextures(), the call to
LayerAndroid::removeTexture() may fail if the texture was busy being
painted -- the call to BackedDoubleBufferedTexture::release() would
return false, and the layer may thus still keep a pointer to the texture.
But the release() call, while indicating it failed, was only delaying
the release -- as soon as the texture was marked as not busy, it
could set its owner to nil.
We could thus have a situation where the layer did not reset its
texture pointers because the owner of the texture was not yet
changed, but the texture would then reset its owner to nil as soon
as it was not busy painting.
In TilesManager::cleanupLayersTexture() the next step before deleting
a texture is to check that the texture does not have an owner -- but
by then the texture could have been marked as not busy, and removed
its owner, letting TilesManager destroying it.
bug:3472320
Change-Id: I3bcf169b30dfacba1773d3b79a3c0d205bf3cbdb
|
| |
| |
| |
| |
| |
| | |
bug:3461349
Change-Id: Id654d176c58027c67be7cb604b87c0ec68984525
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using existing Skia APIs, FontCache::createFontPlatformData can detect
when the retrieved font is the Skia default and will reject that choice,
allowing WebCore to try the next font on the CSS fallback list. If the
requested family is a generic family, e.g. "serif" or "monotype", the
Skia default will be accepted.
A prior attempt at this fix was not properly handling bold and italic
stylings, which could eventually lead to dangling references to freed
font data used for layout while custom fonts were loading, causing
segfaults in getChild and elsewhere during page rendering.
Bug: 3469204
Bug: 2720133
Change-Id: I3a9e746e18fd27848d0c4b9e1232392df33254a6
|
| |
| |
| |
| |
| | |
issue: 4094300
Change-Id: If8e58daa621e01ac372f2111ebde522a6f90b2e5
|
|\ \ |
|
| |/
| |
| |
| |
| | |
bug: 4098273
Change-Id: Iaf7eaa13b9d4410dfb984af0e4a83dadedb09648
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug:4080127
Inset the track by half the width of the thumb so the thumb
travels along the entire length of it.
Make the track narrower vertically, and align it with the
center of the thumb drawing.
Draw the portion of the track that has already been covered
with a different asset.
Change-Id: I37acedc8e8b75bab59fcac7e075c59d70550795c
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We currently rely on the fact that nvidia serializes glFlush calls
to ensure synchronization, but we should be using fences to handle
this synchronization step.
bug: 4098273
Change-Id: I13c4790434dea07d9da68b8ebebbba15b1e085a5
|