Google image search zoom touch handler hangs
Reported by
xachinsh...@gmail.com,
Oct 4 2016
|
||||||||||||||||||||||||||||||||||||
Issue descriptionDevice name: Nexus 4, Nexus 6P From "Settings > About Chrome" Application version: Chrome Beta 54.0.2840.42 OS: Android 6.0.1 URLs (if applicable): Behavior in Android Browser (if applicable): Steps to reproduce: (1) Open Browser, search for "cars" (2) Tap Images (3) Tap any Image (4) Tap the image again to make it go full screen (5) Pinch zoom in and out rapidly Expected result: The image should keep zooming in and out Actual result: Tab freezes. To recover, tap the Overview button
,
Oct 4 2016
,
Oct 4 2016
James, is this something you'd be able to triage?
,
Oct 4 2016
I'll see what I can do ... I just tried with an Android 7 on a Nexus 5x and didn't see the behaviour, so it may take some effort to get a similar config to test. xachinsharma@ ... does the same thing happen if you open a page in the Chrome browser, and repeatedly pinch-zoom it too?
,
Oct 4 2016
I can repro on 54.0.2840.42/Nexus 6P/NME42. Nothing to do with pinch zoom, this is a JS touch handler. No repro on 53.0.2785.134 (on that version, there are 1-second hangs but not permanent ones). Going to homescreen and back fixes the hang, but pressing back button doesn't. Seems worth blocking stable. input-team, can you take a look? Note that if you need to bisect, it's possible to exact bisect using the builds at https://pantheon.corp.google.com/storage/browser/chrome-perf
,
Oct 4 2016
Trace attached. There are two hangs in the trace, the one that says PendingTree::waiting is the temporary hang that also reproes in M53, and then in the later part of the trace it froze forever.
,
Oct 5 2016
Dave, this seems fairly related to the event queue work you've been touching recently, want to take a look? Could this be do to the main / compositor shared event buffer?
,
Oct 5 2016
If you look at the trace. The events are going into the touch_event_queue but aren't leaving that. 1) either an ack isn't being returned 2) some state is somehow wrong in the touch event queue I see an ack for the last event so my guess is #2 there appears to be a lot of logic around the touch sequence.
,
Oct 5 2016
Another interesting thing is that if you rotate the device it doesn't redo a layout. If events were just somehow paused I'd assume that rotation would correctly redo layout. But looking at top in adb shell; cpu utilization seems low (8%-9%) so maybe the main thread isn't run away.
,
Oct 5 2016
If this is going to block M54 stable, it needs to be fixed and merged back to M54 branch 2840 by 5 PM PT on Oct 11, less than one week from today. Please work to get this fixed ASAP.
,
Oct 5 2016
I've been working on it today. It seems the main thread is gone off the rails doing something. I end up doing a PostTask to the main thread from the compositor thread and it doesn't end up getting run. Trying to get a stack trace of what the main thread is doing.
,
Oct 6 2016
danakj@ can you get someone to look at this? It appears the main thread is stuck waiting on CC. And that causes our input to end up not getting processed.
Don't know if this is a duplicate of any bugs already.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) thread 16
[Switching to thread 16 (Thread 28679.28700)]
#0 0xb6e463b8 in syscall () from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
(gdb) bt
#0 0xb6e463b8 in syscall () from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#1 0xb6e49a84 in __pthread_cond_timedwait_relative(pthread_cond_t*, pthread_mutex_t*, timespec const*) () from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#2 0xa35f39fc in base::WaitableEvent::TimedWait (this=this@entry=0xa3abb2b0,
max_time=-1 day, 23:59:59)
at ../../base/synchronization/waitable_event_posix.cc:219
#3 0xa35f3a8e in base::WaitableEvent::Wait (this=this@entry=0xa3abb2b0)
at ../../base/synchronization/waitable_event_posix.cc:156
#4 0xa1d0b896 in cc::CompletionEvent::Wait (this=0xa3abb2b0)
at ../../cc/base/completion_event.h:43
#5 cc::ProxyMain::BeginMainFrame (this=0xaed73510, begin_main_frame_state=...)
at ../../cc/trees/proxy_main.cc:237
#6 0xa1d11e7a in base::internal::FunctorTraits<void (cc::ProxyMain::*)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), void>::Invoke<base::WeakPtr<cc::ProxyMain> const&, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > >(void (cc::ProxyMain::*)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain> const&, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >&&) (
receiver_ptr=base::WeakPtr((cc::ProxyMain *)0xaed73510), method=
(void (cc::ProxyMain::*)(cc::ProxyMain * const, std::__ndk1::unique_ptr<cc::---Type <return> to continue, or q <return> to quit---
BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)) 0xa1d0b571 <cc::ProxyMain::BeginMainFrame(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)>) at ../../base/bind_internal.h:214
#7 base::internal::InvokeHelper<true, void>::MakeItSo<void (cc::ProxyMain::* const&)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain> const&, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > >(void (cc::ProxyMain::* const&)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain> const&, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >&&) (
weak_ptr=base::WeakPtr((cc::ProxyMain *)0xaed73510), functor=
@0x9b4fd138: (void (cc::ProxyMain::*)(cc::ProxyMain * const, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)) 0xa1d0b571 <cc::ProxyMain::BeginMainFrame(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)>) at ../../base/bind_internal.h:305
#8 base::internal::Invoker<base::internal::BindState<void (cc::ProxyMain::*)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, ---Type <return> to continue, or q <return> to quit---
std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > > >, void ()>::RunImpl<void (cc::ProxyMain::* const&)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), std::__ndk1::tuple<base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > > > const&, 0u, 1u>(void (cc::ProxyMain::* const&)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), std::__ndk1::tuple<base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > > > const&, base::IndexSequence<0u, 1u>) (bound=...,
functor=
@0x9b4fd138: (void (cc::ProxyMain::*)(cc::ProxyMain * const, std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)) 0xa1d0b571 <cc::ProxyMain::BeginMainFrame(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >)>) at ../../base/bind_internal.h:364
#9 base::internal::Invoker<base::internal::BindState<void (cc::ProxyMain::*)(std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> >), base::WeakPtr<cc::ProxyMain>, base::internal::PassedWrapper<std::__ndk1::unique_ptr<cc::BeginMainFrameAndCommitState, std::__ndk1::default_delete<cc::BeginMainFrameAndCommitState> > > >, void ()>::Run(base::internal::BindStateBase*) (base=0x9b4fd128)
---Type <return> to continue, or q <return> to quit---
at ../../base/bind_internal.h:342
#10 0xa35c0b82 in base::internal::RunMixin<base::Callback<void (), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> >::Run() const (this=0xa3abb538)
at ../../base/callback.h:64
#11 base::debug::TaskAnnotator::RunTask (this=this@entry=0xaec8d400,
queue_function=0xa1ad57e9 "TaskQueueManager::PostTask",
pending_task=From BeginMainFrame()@../../cc/trees/threaded_channel.cc:255 = {...}) at ../../base/debug/task_annotator.cc:54
#12 0xa19db4c6 in blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue
(this=this@entry=0xaec8d3c0, work_queue=<optimized out>)
at ../../third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:344
#13 0xa19db8c8 in blink::scheduler::TaskQueueManager::DoWork (this=0xaec8d3c0,
run_time=0:00:00, from_main_thread=false)
at ../../third_party/WebKit/Source/platform/scheduler/base/task_queue_manager.cc:240
#14 0xa19da1a0 in base::internal::FunctorTraits<void (blink::scheduler::TaskQueueManager::*)(base::TimeTicks, bool), void>::Invoke<base::WeakPtr<blink::scheduler::TaskQueueManager> const&, base::TimeTicks const&, bool const&> (
receiver_ptr=base::WeakPtr((blink::scheduler::TaskQueueManager *)0xaec8d3c0), method=
(void (blink::scheduler::TaskQueueManager::*)(blink::scheduler::TaskQueueManager * const, base::TimeTicks, bool)) 0xa19db735 <blink::scheduler::TaskQueueMan---Type <return> to continue, or q <return> to quit---
ager::DoWork(base::TimeTicks, bool)>) at ../../base/bind_internal.h:214
#15 base::internal::InvokeHelper<true, void>::MakeItSo<void (blink::scheduler::TaskQueueManager::* const&)(base::TimeTicks, bool), base::WeakPtr<blink::scheduler::TaskQueueManager> const&, base::TimeTicks const&, bool const&> (
weak_ptr=base::WeakPtr((blink::scheduler::TaskQueueManager *)0xaec8d3c0),
functor=
@0xaeca30e0: (void (blink::scheduler::TaskQueueManager::*)(blink::scheduler::TaskQueueManager * const, base::TimeTicks, bool)) 0xa19db735 <blink::scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool)>)
at ../../base/bind_internal.h:305
#16 base::internal::Invoker<base::internal::BindState<void (blink::scheduler::TaskQueueManager::*)(base::TimeTicks, bool), base::WeakPtr<blink::scheduler::TaskQueueManager>, base::TimeTicks, bool>, void ()>::RunImpl<void (blink::scheduler::TaskQueueManager::* const&)(base::TimeTicks, bool), std::__ndk1::tuple<base::WeakPtr<blink::scheduler::TaskQueueManager>, base::TimeTicks, bool> const&, 0u, 1u, 2u>(void (blink::scheduler::TaskQueueManager::* const&)(base::TimeTicks, bool), std::__ndk1::tuple<base::WeakPtr<blink::scheduler::TaskQueueManager>, base::TimeTicks, bool> const&, base::IndexSequence<0u, 1u, 2u>) (bound=..., functor=
@0xaeca30e0: (void (blink::scheduler::TaskQueueManager::*)(blink::scheduler::TaskQueueManager * const, base::TimeTicks, bool)) 0xa19db735 <blink::scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool)>)
at ../../base/bind_internal.h:364
#17 base::internal::Invoker<base::internal::BindState<void (blink::scheduler::Ta---Type <return> to continue, or q <return> to quit---
skQueueManager::*)(base::TimeTicks, bool), base::WeakPtr<blink::scheduler::TaskQueueManager>, base::TimeTicks, bool>, void ()>::Run(base::internal::BindStateBase*) (base=0xaeca30d0) at ../../base/bind_internal.h:342
#18 0xa35c0b82 in base::internal::RunMixin<base::Callback<void (), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> >::Run() const (this=0xa3abb880)
at ../../base/callback.h:64
#19 base::debug::TaskAnnotator::RunTask (this=this@entry=0xaec524ec,
queue_function=0xa363bce8 "MessageLoop::PostTask",
pending_task=From PushOntoImmediateIncomingQueueLocked()@../../third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.cc:285 = {...})
at ../../base/debug/task_annotator.cc:54
#20 0xa35d4a4a in base::MessageLoop::RunTask (this=this@entry=0xaec52440,
pending_task=From PushOntoImmediateIncomingQueueLocked()@../../third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.cc:285 = {...})
at ../../base/message_loop/message_loop.cc:405
#21 0xa35d4ef8 in base::MessageLoop::DeferOrRunPendingTask (
this=this@entry=0xaec52440,
pending_task=From PushOntoImmediateIncomingQueueLocked()@../../third_party/WebKit/Source/platform/scheduler/base/task_queue_impl.cc:285 = {...})
at ../../base/message_loop/message_loop.cc:414
#22 0xa35d5172 in base::MessageLoop::DoWork (this=0xaec52440)
at ../../base/message_loop/message_loop.cc:513
#23 0xa35d5e34 in base::MessagePumpDefault::Run (this=0xaec29af0,
---Type <return> to continue, or q <return> to quit---
delegate=0xaec52440) at ../../base/message_loop/message_pump_default.cc:35
#24 0xa35e7278 in base::RunLoop::Run (this=this@entry=0xa3abb930)
at ../../base/run_loop.cc:35
#25 0xa03d4e86 in content::RendererMain (parameters=...)
at ../../content/renderer/renderer_main.cc:198
#26 0xa041d7b4 in content::ContentMainRunnerImpl::Run (this=0xaec307b8)
at ../../content/app/content_main_runner.cc:786
#27 0xa041cace in content::Start (env=<optimized out>, clazz=...)
at ../../content/app/android/content_main.cc:46
#28 content::Java_org_chromium_content_app_ContentMain_nativeStart (
env=<optimized out>, jcaller=<optimized out>)
at gen/content/public/android/content_jni_headers/content/jni/ContentMain_jni.h:38
#29 0xaf302ab6 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
,
Oct 6 2016
Could this be related to unified BeginFrame?
,
Oct 6 2016
FWIW the compositor thread seems idle to me. So it doesn't look like a deadlock. But a condition never met.
(gdb) bt
#0 0xb6e463b8 in syscall () from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#1 0xb6e49a84 in __pthread_cond_timedwait_relative(pthread_cond_t*, pthread_mutex_t*, timespec const*) () from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#2 0xa35f39fc in base::WaitableEvent::TimedWait (this=this@entry=0xb4af2e28,
max_time=-1 day, 23:59:59)
at ../../base/synchronization/waitable_event_posix.cc:219
#3 0xa35f3a8e in base::WaitableEvent::Wait (this=this@entry=0xb4af2e28)
at ../../base/synchronization/waitable_event_posix.cc:156
#4 0xa35d5e72 in base::MessagePumpDefault::Run (this=0xb4af2e20,
delegate=0xaec528a0) at ../../base/message_loop/message_pump_default.cc:55
#5 0xa35e7278 in base::RunLoop::Run (this=0x9d601d40)
at ../../base/run_loop.cc:35
#6 0xa3602b64 in base::Thread::ThreadMain (this=0xaece0380)
at ../../base/threading/thread.cc:333
#7 0xa35ff03c in base::(anonymous namespace)::ThreadFunc (
params=<optimized out>) at ../../base/threading/platform_thread_posix.cc:71
#8 0xb6e49bb0 in __pthread_start(void*) ()
from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#9 0xb6e47af4 in __start_thread ()
from /tmp/dtapuska-adb-gdb-libs/system/lib/libc.so
#10 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
,
Oct 6 2016
FYI, I'm starting to manually bisect. Will update this bug when I know the culprit.
,
Oct 6 2016
> FWIW the compositor thread seems idle to me. So it doesn't look like a deadlock. But a condition never met. That sounds like a scheduling problem. Thanks for bisecting aelias.
,
Oct 6 2016
Assigning to bisect for now.
,
Oct 6 2016
I could not exact bisect with prebuilts. I have narrowed the range to a patch cherry-picked to 54 in: https://chromium.googlesource.com/chromium/src/+log/54.0.2840.14..54.0.2840.15?pretty=fuller&n=10000
,
Oct 6 2016
I am suspicious of 8d9a5f91b19c30f88e0a9812abf2e936a38dbd0b "Reland of Default enable main frame before activation and remove finch experiment."
,
Oct 6 2016
,
Oct 6 2016
Captured a trace with cc.debug.scheduler enabled. The commit one frame before when main thread gets stuck never activates. The activation/draw/all task sets finished and we get the ready to draw callback.
,
Oct 7 2016
From the trace it _looks_ like we might be out of memory while in smoothness takes priority. (I'm not sure why that would be the case though, but that's an aside). That means we still prioritize visible tiles and we don't mark required for activation tiles as oom while in smoothness takes priority. I think the best way out of this is to exit smoothness takes priority, tbh. Is it possible for you to record a trace with cc.debug as well? If we see BuildEvictionQueue slices in there, then that would confirm that we're out of memory. I think also some of our tracing reporting in tile manager is kind of wrong. Like we say that all tiles required now have memory, but that refers to NOW tiles, and there is a set of active tree soon tiles that may also be required for activation and this doesn't capture it...
,
Oct 7 2016
Can't reproduce this with or without main frame before activation on nexus 5. On 6p I can reproduce it with both MFBA enabled/disabled. When MFBA is enabled main thread is stuck on commit because previous pending tree is not activated but that's a red herring. Even if the main thread is not busy (MFBA disabled trace attached) it will remain idle as long as activation happens. Vlad, do you have any ideas?
,
Oct 7 2016
There was definitely a preexisting problem on 53 (~1 second janks). MFBA may have just increased the severity.
,
Oct 7 2016
Are we also able to change this conditional wait to a timed wait with a really long expiration and then crash the renderer if it expires? We have had reports on desktop that input no longer is consumed and it would be great if we could detect the rate of failures in this kind of fault in the crash reports.
,
Oct 7 2016
If my theory in #22 is correct, then one difference between 5 and 6p is that 6p would use more memory for tiles thus entering this state more reliably. Why aren't we exiting smoothness takes priority mode? Is it because there's continuous input? I think the proposal in #25 is also reasonable. Right now we don't really have a way to detect how often cases like pending tree never activating is happening, if we can crash the renderer after some reasonable time (60sec?) then we'd get reports.
,
Oct 7 2016
Vlad, here's a trace with cc.debug (MFBA is disabled). There's a BuildEvictionQueue slice just before the long pending tree period.
,
Oct 7 2016
Yeah, it looks like we unconditionally set smoothness takes priority 0.25s after an input/gesture (if we're still in a gesture). Maybe TileManager should inform LTHI that OOM tiles exist and LTHI should unconditionally set NEW_CONTENT_TAKES_PRIORITY in that case?
,
Oct 7 2016
Yeah that looks like out of memory issue. I'm going to write up a little fix that should alleviate this problem by properly flagging soon required for activation tiles as able to use the hard memory limit. That doesn't really fix the issue, since we just need more layers to have this triggered again though.
,
Oct 7 2016
,
Oct 7 2016
[Bulk edit] URGENT: This issue is marked as an RB-Stable for Android M54. If it is going to block the release, it needs to be fixed ASAP, and merged back to branch 2840 by 5 PM PT Oct 11. Please review and if you cannot get it fixed by then, ping me; if you don't believe you are the right owner, and you cannot find another one - please ping me.
,
Oct 7 2016
This CL did not alleviate the issue: https://codereview.chromium.org/2407443002/ See attached trace.
,
Oct 8 2016
I have a few patches (sunnyps@ has links :) ) that help the issue to a degree, but don't eliminate it altogether. What's left is not trivial to fix. That is, when processing active tree soon rect that may contain required for activation tiles, we need to probably do two passes over the rects in order to require required for activation tiles first. I'll work on that fix on Monday. Meanwhile, one of the patches I have allows us to activate using OOM method in smoothness takes priority. This means that essentially you may see some checkerboards, but activation will not be blocked. This is similar to how we activate non-accelerated gesture oom situations. Should we land that as a temporary fix?
,
Oct 8 2016
If that just purely replaces the permanent hang scenario with a transient-visual-glitch scenario and it doesn't raise any other risk, then yes. If the story is more complicated than that, I'm not certain.
,
Oct 10 2016
@34, yes, that's the case. We'll simply activate to checkers. I think it's a good change in general, since even a proper fix to this bug will only fix this specific page. To elaborate a little bit, we have two memory limits (hard and soft), hard limit is the limit we're allowed to use for NOW bin tiles, since they are visible and may go up to the hard memory limit. The soft memory limit, which is smaller, is used for prepaint to ensure we don't fill up all the memory if we don't need to. The bug here is that we can have tiles in the SOON bin that are required for activation. These are the tiles that are on the active tree outside of the viewport. However, upon activation these tiles will be in the viewport (since the pending tree has a different viewport). So the bug is that these required for activation tiles are using the soft memory limit, not the hard one. If we fix this (and I think I have a fix now here: https://codereview.chromium.org/2406753004, which marks active tree tiles in pending tree's visible rect as NOW bin), we'll use the hard memory limit for activation. However, it can still be the case that this limit is not enough for us to activate. So as long as we remain in smoothness takes priority, we won't activate. The initial motivation for not activating in smoothness takes priority is that we want to have memory for scrolling new content into view instead of the pending tree. However, I don't really think it's a good idea specifically because of bugs like this one. Basically, I'd like to land both the fix referenced here to see if it solves the immediate issue _and_ to land a patch that allows us to activate in oom smoothness takes priority cases to prevent this from happening with different pages. I've asked sunnyps@ to verify if the patch I have fixes the issue, so if it's a go, then we can land that and then land the other patch to activate to checkers as a follow-up.
,
Oct 10 2016
Let's make sure this these patches land on trunk by 3 PM PT today, so that they can be included / verified in our canary release tomorrow. Ping me if this will be an issue, thanks. Also tagging this with M-55 as I'd assume the same issues persist on branch 2883, remove the M-55 label if this is incorrect.
,
Oct 10 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7d2136eca32d2ad075122b8210d47d8ab2315070 commit 7d2136eca32d2ad075122b8210d47d8ab2315070 Author: vmpstr <vmpstr@chromium.org> Date: Mon Oct 10 21:21:14 2016 cc: Make pending visible rect active tree tiles be in the NOW bin. This patch changes the BINs of the active tree tiles that lie in the pending tree's visible rect be in the NOW bin. This change is to ensure that these tiles are allowed to use the hard memory limit in the tile manager, since they may contain tiles that are required for activation. R=sunnyps@chromium.org BUG= 652884 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2406753004 Cr-Commit-Position: refs/heads/master@{#424244} [modify] https://crrev.com/7d2136eca32d2ad075122b8210d47d8ab2315070/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/7d2136eca32d2ad075122b8210d47d8ab2315070/cc/tiles/raster_tile_priority_queue_all.cc [modify] https://crrev.com/7d2136eca32d2ad075122b8210d47d8ab2315070/cc/tiles/tile_manager_unittest.cc
,
Oct 11 2016
Approving merges for M54 (branch 2840) and M55 (branch 2883).
,
Oct 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92416983a6c284feebb491097691dc0ed99653bc commit 92416983a6c284feebb491097691dc0ed99653bc Author: Vladimir Levin <vmpstr@chromium.org> Date: Tue Oct 11 21:02:25 2016 cc: Make pending visible rect active tree tiles be in the NOW bin. This patch changes the BINs of the active tree tiles that lie in the pending tree's visible rect be in the NOW bin. This change is to ensure that these tiles are allowed to use the hard memory limit in the tile manager, since they may contain tiles that are required for activation. R=sunnyps@chromium.org BUG= 652884 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2406753004 Cr-Commit-Position: refs/heads/master@{#424244} (cherry picked from commit 7d2136eca32d2ad075122b8210d47d8ab2315070) Review URL: https://codereview.chromium.org/2409393002 . Cr-Commit-Position: refs/branch-heads/2883@{#45} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/raster_tile_priority_queue_all.cc [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/tile_manager_unittest.cc
,
Oct 11 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/48cbc1e27d680b79c3cf184148dc30f3401ad402 commit 48cbc1e27d680b79c3cf184148dc30f3401ad402 Author: Vladimir Levin <vmpstr@chromium.org> Date: Tue Oct 11 21:14:43 2016 cc: Make pending visible rect active tree tiles be in the NOW bin. This patch changes the BINs of the active tree tiles that lie in the pending tree's visible rect be in the NOW bin. This change is to ensure that these tiles are allowed to use the hard memory limit in the tile manager, since they may contain tiles that are required for activation. R=sunnyps@chromium.org BUG= 652884 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2406753004 Cr-Commit-Position: refs/heads/master@{#424244} (cherry picked from commit 7d2136eca32d2ad075122b8210d47d8ab2315070) Review URL: https://codereview.chromium.org/2404423002 . Cr-Commit-Position: refs/branch-heads/2840@{#722} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/raster_tile_priority_queue_all.cc [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/tile_manager_unittest.cc
,
Oct 11 2016
,
Oct 18 2016
Verified on Nexus 4/LMY49S with latest chrome dev M55 release.
,
Oct 19 2016
Verified on Nexus 4/LMY48T with M54 Stable release.
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/92416983a6c284feebb491097691dc0ed99653bc commit 92416983a6c284feebb491097691dc0ed99653bc Author: Vladimir Levin <vmpstr@chromium.org> Date: Tue Oct 11 21:02:25 2016 cc: Make pending visible rect active tree tiles be in the NOW bin. This patch changes the BINs of the active tree tiles that lie in the pending tree's visible rect be in the NOW bin. This change is to ensure that these tiles are allowed to use the hard memory limit in the tile manager, since they may contain tiles that are required for activation. R=sunnyps@chromium.org BUG= 652884 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2406753004 Cr-Commit-Position: refs/heads/master@{#424244} (cherry picked from commit 7d2136eca32d2ad075122b8210d47d8ab2315070) Review URL: https://codereview.chromium.org/2409393002 . Cr-Commit-Position: refs/branch-heads/2883@{#45} Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768} [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/raster_tile_priority_queue_all.cc [modify] https://crrev.com/92416983a6c284feebb491097691dc0ed99653bc/cc/tiles/tile_manager_unittest.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/48cbc1e27d680b79c3cf184148dc30f3401ad402 commit 48cbc1e27d680b79c3cf184148dc30f3401ad402 Author: Vladimir Levin <vmpstr@chromium.org> Date: Tue Oct 11 21:14:43 2016 cc: Make pending visible rect active tree tiles be in the NOW bin. This patch changes the BINs of the active tree tiles that lie in the pending tree's visible rect be in the NOW bin. This change is to ensure that these tiles are allowed to use the hard memory limit in the tile manager, since they may contain tiles that are required for activation. R=sunnyps@chromium.org BUG= 652884 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2406753004 Cr-Commit-Position: refs/heads/master@{#424244} (cherry picked from commit 7d2136eca32d2ad075122b8210d47d8ab2315070) Review URL: https://codereview.chromium.org/2404423002 . Cr-Commit-Position: refs/branch-heads/2840@{#722} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/raster_tile_priority_queue_all.cc [modify] https://crrev.com/48cbc1e27d680b79c3cf184148dc30f3401ad402/cc/tiles/tile_manager_unittest.cc |
||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||
Comment 1 by pdr@chromium.org
, Oct 4 2016Status: Untriaged (was: Unconfirmed)