1. 05 Nov, 2018 4 commits
    • Ilya Sherman's avatar
      Clean up the Java method name for recording a sparse histogram · 9dae03c6
      Ilya Sherman authored
      There is no reason to include "slowly" in this method name, as it's not
      meaningfully slower than any other histogram that might be recorded in Java. (I
      would expect any JNI calls to dominate the runtime performance.)
      
      TBR=jochen@chromium.org
      
      Bug: None
      Change-Id: Id606696351783a5b39fa7908cbc3f3d681188567
      Reviewed-on: https://chromium-review.googlesource.com/c/1313672Reviewed-by: default avatarTheresa <twellington@chromium.org>
      Commit-Queue: Ilya Sherman <isherman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#605215}
      9dae03c6
    • chromium-autoroll's avatar
      Roll Fuchsia SDK from 2d570972bf85 to 0b293da5f934 · e46d04c7
      chromium-autoroll authored
      
      The AutoRoll server is located here: https://autoroll.skia.org/r/fuchsia-sdk-chromium-autoroll
      
      Documentation for the AutoRoller is here:
      https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
      
      If the roll is causing failures, please contact the current sheriff, who should
      be CC'd on the roll, and stop the roller if necessary.
      
      
      CQ_INCLUDE_TRYBOTS=luci.chromium.try:fuchsia_arm64_cast_audio;luci.chromium.try:fuchsia_x64_cast_audio
      TBR=cr-fuchsia+bot@chromium.org
      
      Change-Id: Ifc4f8515bb5a26edbdbdd595c88ef943d701fbd7
      Reviewed-on: https://chromium-review.googlesource.com/c/1317172Reviewed-by: default avatarchromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
      Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#605214}
      e46d04c7
    • Giovanni Ortuño Urquidi's avatar
      bluetooth: Move controller logic out of BluetoothDetailedView · 9d948785
      Giovanni Ortuño Urquidi authored
      For the most part, this CL just moves the controller logic out of
      BluetoothDetailedView and into UnifiedBluetoothDetailedViewController.
      
      But there are three exceptions:
      
      1. Before, Layout() was called at the end of
         BluetoothDetailedView::DoUpdate(). Now, Layout() is called
         indirectly in UpdateDeviceScrollList() through,
         ShowBluetoothDisabledPanel, HideBluetoothDisabledPanel, and
         BluetoothDetailedView::UpdateDeviceScrollList().
      
      2. BluetoothDetailedView::UpdateDeviceScrollList() used to perform the
         following steps:
      
         1. Clear the device list
         2. If state is not "powered" show the "bluetooth disabled" panel
            and return.
         3. Otherwise hide the "bluetooth disabled" panel.
         4. Update the device list.
      
         Now UBDVC::UpdateDeviceScrollList() performs the following steps:
      
         1. If state is not "powered" then call
            BDV::ShowBluetoothDisabledPanel() and return
           1.1. Clear device list
           1.2. Show "bluetooth disabled" panel
         2. Otherwise call BDV::HideBluetoothDisabledPanel()
           2.1. Hide "bluetooth disabled" panel
         3. Call BDV::UpdateDeviceScrollList()
           3.1. Clear device list
           3.2. Populate device list with current devices.
      
         Similar set of steps but except that "clear device list" is
         performed by two separate functions.
      
      3. Discovery stops when UnifiedBluetoothDetailedViewController gets
         destroyed. Before, discovery was stopped when BluetoothDetailedView
         was destroyed.
      
      
      Change-Id: I4727bcdf35e0f84ab16ff0bace8f3d89aefc58de
      Reviewed-on: https://chromium-review.googlesource.com/c/1308241
      Commit-Queue: Giovanni Ortuño Urquidi <ortuno@chromium.org>
      Reviewed-by: default avatarYoshiki Iguchi <yoshiki@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#605213}
      9d948785
    • Eric Karl's avatar
      Android OOP-D: Delay establishing Viz connection until needed · 08ea554f
      Eric Karl authored
      To make Viz's GPU proc startup more like non-Viz, and hopefully avoid
      the increased crash rate when trying to connect, this change delays
      establishing the connection to the Viz/GPU process until we establish
      our first GpuChannel.
      
      TBRing fsamuel as I want to get this baking in tonight's Canary for
      potential mergethis tuesday.
      
      TBR=fsamuel@chromium.org
      
      Bug: 897272
      Change-Id: I4234040a58cb5af13594adf2e1d9287b043aac1b
      Reviewed-on: https://chromium-review.googlesource.com/c/1317031
      Commit-Queue: Eric Karl <ericrk@chromium.org>
      Reviewed-by: default avatarEric Karl <ericrk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#605212}
      08ea554f
  2. 04 Nov, 2018 15 commits
  3. 03 Nov, 2018 21 commits