| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
We fixed two issues here.
First, when fixed left/right both undefined, the renderlayer position already
took the fix margin into consideration, so we don't need to compute that again.
Second, for compute the fix element's ViewRect, we just need the normal width,
not the overflow one.
bug:4440999
Change-Id: I664c64688a89579f0023288185772c61b01c7cc8
|
|\ \
| | |
| | |
| | | |
Change-Id: Ib6fbd07827ffba629ed5a560c58e5d005f4d4c75
|
| | |\ |
|
| | | |\
| | |/ / |
|
| | | |\
| | |/ / |
|
| | | |\
| | |/ / |
|
| | | |\
| | |/ / |
|
| | | |\
| | |/ / |
|
| | | |\
| | |/ / |
|
| | | |\ |
|
| | | | |\
| | | |/ / |
|
| | | | |\
| | | |/ / |
|
| | | | |\ |
|
| | | | | |\
| | | | |/ / |
|
| | | | | |\
| | | | |/ / |
|
| | | | | |\ |
|
| | | | | | |\ |
|
| | | | | | | |\ |
|
| | | | | | | | |\ |
|
| | | | | | | | | |\
| | | | | | | | |/ / |
|
| | | | | | | | | |\ |
|
| | | | | | | | | | |\ |
|
| | | | | | | | | | | |\
| | | | | | | | | | |/ / |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
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
|
| | | | | | | | | | | |\ |
|
| | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
This should help out in some cases with redirect/login loops.
Bug: 4110115
Change-Id: I42fff7e9227423b9b5ce94234ad6d606234fe252
|
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
Don't save the extras in the picture when drawing.
bug:4126884 bug:4132721
Change-Id: I52c46a33f847e64c1f8245a0bb84445a948d72a4
|
| | | | | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
bug:4124433
Change-Id: I8cc7203dad408eff30da33f1c9a0a77dd7c97d66
|
| | | | | | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |
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
|
| | | | | | | | | | | | | | | | | |\ |
|
| | | | | | | | | | | | | | | | | | |\
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | |
honeycomb-mr1-release
|
| | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
The shape of the text selection changed recently, so the
inval computation for the shape area was slightly incorrect.
But most of the problem is caused by multiple calls to
draw the selection area. The old assumption was that
successive calls to compute the inval could each work
from the prior state, since only the difference between
the last inval and the current inval needs to be redrawn.
Now, there are multiple calls to compute the area, and any
of them need to return the last difference computed, only
computing a new difference if the selection changed.
Keep track of the last changed selection, so that the last
position, the current position, and the last drawn position
can be tracked correctly.
bug:4073219
Change-Id: Ic9b9d037329e8f792b5ec09c112e665dbdfd0b81
|
| | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | |
We were not resetting the unusable state (set by the clearView()
function) when receiving new content...
bug:4080072
Change-Id: Ie1110b511392b0a7fd21bbc23aa1b824eb8a78ad
|
| | | | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | | | | | |\ \
| | | | | | | | | | | | | | | | | | | | | | | | | |/ / / |
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Wait the remaining of the 60FPS cap delay rather than not paint.
Returning true if called faster than 60FPS means
we are not drawing and ask for the framework to call
us again; this works in general because the framework recopy
the previous framebuffer. But in some cases, it didn't, causing
the webview to flicker. A correct fix would be to introduce
the capping in framework rather than try to doing it in the
webview; in the meantime we will sleep the remaining of the delay
as a workaround, so that we still provide the GPU
benefits we wanted (at >60FPS the GPU was being saturated in
some cases).
bug:3500655
Change-Id: Ibaa1d93e0a13433a2c842b19b58538894fdaa7e4
|
| | | | | | | | | | | | | | | | | | | | | | | | | | |\ \ |
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
The dtor of GLWebViewState is calling the dtor of its TiledPage
variables; the dtor of TiledPage wait until any pending painting
operations running in the TextureGenerator thread are done. The painting
operations ultimately paint using the current GLWebViewState's base
layer. We were doing unref() on the baselayer before destroying the
TiledPage...
bug:3429924
Change-Id: I685e7fca5e5bae796f808debbf7e4ce668b83e6b
|