text:
<!--
Copyright 2020 The Chromium Authors
Use of this source code is governed by a BSD-style license that can be
found in the LICENSE file.
-->

<!--
This file is used to generate a comprehensive list of Compositing histograms
along with a detailed description for each histogram.

For best practices on writing histogram descriptions, see
https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histograms/README.md

Please follow the instructions in the OWNERS file in this directory to find a
reviewer. If no OWNERS file exists, please consider signing up at
go/reviewing-metrics (Googlers only), as all subdirectories are expected to
have an OWNERS file. As a last resort you can send the CL to
chromium-metrics-reviews@google.com.
-->

<histogram-configuration>

<histograms>

<histogram name="Compositing.Browser.GPUMemoryForTilingsInKb" units="Kb"
    expires_after="2023-05-14">
  <owner>pdr@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <owner>sky@chromium.org</owner>
  <summary>
    Warning: this histogram was expired from ~9/2020 to ~8/2021.

    The GPU memory allocated for tilings (in a browser process), summed over all
    picture layers. Emitted once per drawing. Nothing is recorded if there are
    no picture layers.

    Tilings are used for decomposition of the layer's entire contents at a
    picture screenspace resolution to do threaded rasterization.
  </summary>
</histogram>

<histogram name="Compositing.Browser.LayersUpdateTime" units="microseconds"
    expires_after="2023-03-19">
  <owner>schenney@chromium.org</owner>
  <owner>animations-dev@chromium.org</owner>
  <summary>
    Time spent updating layers, in microseconds. Recorded when layers are
    updated (in a browser process).

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Compositing.Browser.LayerTreeImpl.CalculateDrawPropertiesUs"
    units="microseconds" expires_after="2023-03-19">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Time spent updating layer draw properties, in microseconds. Recorded when a
    LayerTreeImpl's draw properties are updated (in a browser process).

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Compositing.Browser.NumActiveLayers" units="layers"
    expires_after="2023-09-11">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of layers in the active tree for each compositor frame. This is
    logged once per frame, before the frame is drawn (in a browser process).
  </summary>
</histogram>

<histogram name="Compositing.Browser.NumActivePictureLayers" units="layers"
    expires_after="2023-09-11">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of PictureLayers in the active tree for each compositor frame.
    This is logged once per frame, before the frame is drawn (in a browser
    process).
  </summary>
</histogram>

<histogram name="Compositing.Browser.NumRenderSurfaces" units="surfaces"
    expires_after="2023-09-11">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of render surfaces in the render surface layer list. Recorded
    each time the render surface layer list is constructed (in a browser
    process).
  </summary>
</histogram>

<histogram name="Compositing.ColorGamut" enum="ColorGamut"
    expires_after="2022-02-06">
  <owner>cblume@chromium.org</owner>
  <owner>khushalsagar@chromium.org</owner>
  <summary>
    Every time a frame is presented, record the generalized color gamut of that
    frame.
  </summary>
</histogram>

<histogram name="Compositing.CopyFromSurfaceTime" units="ms"
    expires_after="2018-08-30">
  <owner>wychen@chromium.org</owner>
  <summary>
    The turn around time taken for the async readback of pixels is measured
    here. This should be marked as obsolete once some tests no longer rely on
    this histogram. See crbug/1110961 for more details.
  </summary>
</histogram>

<histogram name="Compositing.DecodeLCPCandidateImage.{DecodeMethod}"
    enum="Boolean" expires_after="2023-01-31">
  <owner>schenney@chromium.org</owner>
  <owner>mmocny@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Reports whether an image decode was for an image that might be used as the
    Largest Contentful Image, and then whether a missing tile at raster time
    includes such an image. The goal is to get an approximate idea of how many
    LCP candidate images miss their frame deadline, and hence how often we may
    report LCP too soon.

    Recorded on every {DecodeMethod}
  </summary>
  <token key="DecodeMethod">
    <variant name="Hardware" summary="hardware image decode task completion."/>
    <variant name="MissedDeadline"
        summary="call to PrepareTiles() in which there was a missing tile.
                 True if any missing tile contains an LCP candidate decode
                 that has not completed."/>
    <variant name="Software" summary="software image decode task completion."/>
  </token>
</histogram>

<histogram name="Compositing.DidMainThreadBlockDuringCommit" enum="Boolean"
    expires_after="2023-03-19">
  <owner>szager@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <owner>sky@chromium.org</owner>
  <summary>
    Recorded on every commit. Indicates whether the renderer's main thread was
    blocked waiting for the impl thread to commit. True indicates the main
    thread did block.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.OverlayProcessingUs"
    units="microseconds" expires_after="2023-03-19">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Time spent processing quads to see which can be replaced with overlays. This
    is logged once per frame, when a frame should be drawn. Only reported for
    platforms supporting high resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.PartialSwap.ExtraDamage" units="%"
    expires_after="2022-10-16">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    The area of the display damage that was added to current frame damage after
    all adjustments, including FrameBufferDamage from buffer queue and render
    pass filters.

    This metric is reported once per frame only on platforms/devices that
    support partial swap and does not include "empty swap" (no frame
    damage) case.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.PartialSwap.FrameBufferDamage"
    units="%" expires_after="2022-10-23">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    The area of the display that was damaged since previous draw to this frame
    buffer.

    This metric is reported once per frame only on platforms/devices that
    support partial swap and does not include "empty swap" (no frame
    damage) case.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.PartialSwap.RootDamage" units="%"
    expires_after="2023-04-30">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    The area of the display that was damaged in current frame.

    This metric is reported only on platforms/devices that support partial swap
    and does not include "empty swap" (no frame damage) case.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.PartialSwap.TotalDamage" units="%"
    expires_after="2023-04-30">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    The total area of the display that will be redrawn this frame.

    This metric is reported only on platforms/devices that support partial swap
    and does not include "empty swap" (no frame damage) case.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.SkipAllNonRootRenderPassesPerFrame"
    enum="BooleanSkipped" expires_after="2023-04-01">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Whether all non-root render passes in a frame are skipped. Logged once per
    frame during DrawFrame for the frames with non-root render passes.
  </summary>
</histogram>

<histogram name="Compositing.DirectRenderer.SkipNonRootRenderPass"
    enum="BooleanSkipped" expires_after="2023-04-01">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Logged for every non-root render pass in DrawRenderPass during DrawFrame.
    True if there is no damages to the render pass and the rendering is skipped.
  </summary>
</histogram>

<histogram name="Compositing.Display.AdpfHintUs" units="microseconds"
    expires_after="2023-03-26">
  <owner>boliu@chromium.org</owner>
  <owner>vasilyt@chromium.org</owner>
  <summary>
    This is logged once for every ADPF performance hint report, which is
    generally once every frame on Android device that supports ADPF and ADPF is
    enabled. It's the interval reported to ADPF, which is currently implemented
    as the wall clock time from vsync frame time to swap_start. Only reported
    for platforms supporting high resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.Draw.Occlusion.Calculation.Time"
    units="microseconds" expires_after="2022-12-18">
  <owner>yiyix@chromium.org</owner>
  <owner>chromeos-gfx@chromium.org</owner>
  <summary>
    Time spent to remove invisible quads from the quad_list in CompositorFrame.

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Compositing.Display.DrawToSwapUs" units="microseconds"
    expires_after="2023-04-09">
  <owner>backer@chromium.org</owner>
  <owner>rjkroege@chromium.org</owner>
  <summary>
    This is logged once per frame, if the output surface provides timing
    information. It measures the time from the display compositor starting a
    draw on the Viz Compositor thread to issuing all related draw calls to the
    driver on the Gpu Main thread. Only reported for platforms supporting high
    resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.DrmOverlayManager.FirstTestPageFlipPassed"
    enum="Boolean" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or more times per frame, whether the first call to
    HardwareDisplayController.TestPageFlip succeeded.
  </summary>
</histogram>

<histogram name="Compositing.Display.DrmOverlayManager.TestPageFlipCount"
    units="units" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or more times per frame, the number of times TestPageFlip is
    called on the HardwareDisplayController.
  </summary>
</histogram>

<histogram name="Compositing.Display.DrmOverlayManager.TestPageFlipUs"
    units="microseconds" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or more times per frame, the duration of calling TestPageFlip on
    the HardwareDisplayController. Only reported for platforms supporting high
    resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.DrmThread.CheckOverlayCapabilitiesSyncUs"
    units="microseconds" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or more times per frame, the duration of
    DrmThread::CheckOverlayCapabilitiesSync(). This is the total time spent on
    the DRM thread to check a set of overlay candidates. Only reported for
    platforms supporting high resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.FlattenedRenderPassCount" units="units"
    expires_after="2023-03-19">
  <owner>backer@chromium.org</owner>
  <owner>rjkroege@chromium.org</owner>
  <summary>
    This is logged once per frame. It is the number of renderer passes after
    flattening all possible render passes. If the value is more than one, then
    an intermediate rendering target must be used during the rendering of the
    frame for each render pass greater than one.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.HardwareDisplayController.SchedulePageFlipResult"
    enum="PageFlipResult" expires_after="2023-03-02">
  <owner>jshargo@chromium.org</owner>
  <owner>seanpaul@chromium.org</owner>
  <owner>chromeos-gfx-compositor@chromium.org</owner>
  <summary>
    Logged once per frame, represents whether we could successfully schedule a
    page flip, or what error we encountered along the way.
  </summary>
</histogram>

<histogram name="Compositing.Display.OverlayCombinationCache.NumIdsEvicted"
    units="units" expires_after="2023-04-02">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or one times per frame, the number of stale candidate ids we are
    evicting from the OverlayCombinationCache this frame. If this number is high
    the CandidateIds or the candidates proposed are likely less stable than they
    should be.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorOzone.HardwareCapabilitiesIsValid"
    enum="Boolean" expires_after="2022-11-30">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    This is logged every time a new HardwareCapabilities is received from DRM
    when display configuration may have changed. True iff the response received
    is valid.
  </summary>
</histogram>

<histogram name="Compositing.Display.OverlayProcessorOzone.MaxPlanesSupported"
    units="units" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    This is logged every time a valid HardwareCapabilities is received from DRM
    when display configuration may have changed. It records the number of
    overlay planes we have available on this device including the primary plane.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.CandidateCombinationPreviouslySucceeded"
    enum="Boolean" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or one times per frame, whether or not the candidate combination
    being tested this frame was successfully promoted to overlays on the
    previous frame.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.CheckOverlaySupportCallCount"
    units="units" expires_after="2023-03-26">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    This is logged once per frame, the number of times CheckOverlaySupport is
    called this frame.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.CheckOverlaySupportUs"
    units="microseconds" expires_after="2023-03-26">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or more times per frame, the time spent checking if a set of
    candidates can be promoted to overlay. Only reported for platforms
    supporting high resolution clocks.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.NumOverlays{Counted}"
    units="overlay candidates" expires_after="2022-11-30">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>Logged once per frame, the number of overlays {Counted}</summary>
  <token key="Counted">
    <variant name="Attempted"
        summary="attempted. This is only logged when using the
                 AttemptMultipleOverlays path."/>
    <variant name="Failed"
        summary="failed. This is only logged when using the
                 AttemptMultipleOverlays path."/>
    <variant name="Promoted" summary="promoted."/>
  </token>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.NumQuadsConsidered"
    units="units" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged once per frame, the number of quads considered for promotion to
    overlay.
  </summary>
</histogram>

<histogram
    name="Compositing.Display.OverlayProcessorUsingStrategy.ShouldAttemptMultipleOverlays"
    enum="AttemptingMultipleOverlays" expires_after="2023-04-16">
  <owner>khaslett@chromium.org</owner>
  <owner>kylechar@chromium.org</owner>
  <summary>
    Logged zero or one times per frame, whether we're using the
    AttemptingMultipleOverlays codepath this frame or why we arent.
  </summary>
</histogram>

<histogram name="Compositing.Display.VizDependencyResolvedToGpuStartedDrawUs"
    units="microseconds" expires_after="2022-12-18">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    This is logged once per frame, if the output surface provides timing
    information. It measures delta between the time when display compositor draw
    task's dependencies have been solved and the time when the Gpu Thread
    started processing it. Only reported for platforms supporting high
    resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.VizScheduledDrawToDependencyResolvedUs"
    units="microseconds" expires_after="2023-04-23">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    This is logged once per frame if the output surface provides timing
    information. It measures delta between the time when display compositor
    scheduled first draw task for the current frame on Viz Compositor thread and
    the time when the task's dependencies have been resolved and the task is
    ready for the Gpu Thread to start processing it. Recorded when swap
    completes. Only reported for platforms supporting high resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.Display.VizScheduledDrawToGpuStartedDrawUs"
    units="microseconds" expires_after="2022-12-18">
  <owner>vasilyt@chromium.org</owner>
  <owner>backer@chromium.org</owner>
  <summary>
    This is logged once per frame if the output surface provides timing
    information. It measures delta between the time when display compositor
    scheduled first draw task for the current frame on Viz Compositor thread and
    the time when Gpu Thread started processing it. Recorded when swap
    completes. Only reported for platforms supporting high resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.MainThreadBlockedDuringCommitTime"
    units="microseconds" expires_after="2023-03-19">
  <owner>szager@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <owner>sky@chromium.org</owner>
  <summary>
    The time that the renderer's main thread blocked waiting for the impl thread
    to commit. This is only reported if the main thread blocked.

    Drops reports on clients with low-resolution clocks, biasing to a portion of
    the population on Windows. See Windows.HasHighResolutionTimeTicks for the
    affected sample.
  </summary>
</histogram>

<histogram
    name="Compositing.MainThreadBlockedDuringCommitTime.ApplyCompositorChanges"
    units="microseconds" expires_after="2023-03-19">
  <owner>szager@chromium.org</owner>
  <owner>pdr@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The time that ApplyCompositorChanges is blocked waiting for the impl thread
    to commit. This is a subset of the total time spent in
    Compositing.MainThreadBlockedDuringCommitTime.

    Drops reports on clients with low-resolution clocks, biasing to a portion of
    the population on Windows. See Windows.HasHighResolutionTimeTicks for the
    affected sample.
  </summary>
</histogram>

<histogram
    name="Compositing.Renderer.CALayer.ChangedIOSurfacesPercentagePerFrame"
    units="%" expires_after="2023-04-23">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <summary>
    The percentage of changed IOSurface number in all IOSurface per frame.
    Recorded during the CALayer Tree commit to CoreAnimation on Mac.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.CALayer.ChangedIOSurfacesPerFrame"
    units="surfaces" expires_after="2023-04-23">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <summary>
    The number of IOSurfaces changed per frame. Recorded during the CALayer Tree
    commit to CoreAnimation on Mac.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.CALayer.ChangedIOSurfacesSizePerFrame"
    units="bytes" expires_after="2023-04-23">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <summary>
    Total IOSurfaces area size updated per frame. Recorded during the CALayer
    Tree commit to CoreAnimation on Mac.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.CALayerResult" enum="CALayerResult"
    expires_after="2023-03-19">
  <owner>ccameron@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    The outcome of attempting to replace all renderer tiles with CALayers.
    Either success, or the first reason why a DrawQuad couldn't be replaced by a
    CALayer.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.CommitHung" units="boolean"
    expires_after="2023-05-14">
  <owner>skobes@chromium.org</owner>
  <owner>input-dev@chromium.org</owner>
  <summary>
    Records when the renderer compositor thread is hung (14 seconds) waiting to
    run the commit after the main thread signalled that it is ready to commit.
  </summary>
</histogram>

<histogram
    name="Compositing.Renderer.FirstSurfaceActivationUpdateDuration.{Surface}"
    units="ms" expires_after="2023-04-28">
  <owner>jonross@chromium.org</owner>
  <owner>chrome-gpu-metrics@google.com</owner>
  <summary>
    The cumulative time spent performing visual updates for the {Surface}.

    The time is measured in the Renderer. The result is reported in the Browser
    when it is notified that the first Surface for a Renderer has been activated
    by the GPU process. This is only reported for the first Surface that is
    activated, and not for subsequent Surfaces.
  </summary>
  <token key="Surface">
    <variant name="CurrentSurface"
        summary="current surface which was activated. This time overlaps with
                 when paint holding is deferring commits, and so is an upper
                 bound"/>
    <variant name="PreviousSurfaces"
        summary="previous surfaces which were not activated. This time might
                 overlap with when paint holding is deferring commits, and so
                 is an upper bound"/>
  </token>
</histogram>

<histogram name="Compositing.Renderer.GPUMemoryForTilingsInKb" units="Kb"
    expires_after="2022-11-09">
  <owner>pdr@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The GPU memory allocated for tilings (in a renderer process), summed over
    all picture layers. Emitted once per drawing. Nothing is recorded if there
    are no picture layers.

    Tilings are used for decomposition of the layer's entire contents at a
    picture screenspace resolution to do threaded rasterization.
  </summary>
</histogram>

<histogram
    name="Compositing.Renderer.LayerSkippedForDrawPropertiesDueToBackface"
    units="boolean" expires_after="2023-01-31">
  <owner>chrishtr@chromium.org</owner>
  <owner>dbaron@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Records whether layer draw properties updates were skipped due to the layer
    being back-facing and not being double-sided, but were otherwise going to be
    updated.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.LayersUpdateTime" units="microseconds"
    expires_after="2023-04-23">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Time spent updating layers, in microseconds. Recorded when layers are
    updated (in a renderer process).

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.LayerUpdateSkippedDueToBackface"
    units="boolean" expires_after="2023-01-31">
  <owner>chrishtr@chromium.org</owner>
  <owner>dbaron@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Records whether a layer update was skipped due to the layer being
    back-facing and not being double-sided, but was otherwise going to be
    updated.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.LCDTextDisallowedReasonKPixels"
    enum="LCDTextDisallowedReason" expires_after="2023-04-16">
  <owner>wangxianzhu@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Records the approximate kilo-pixels covered by text drawing operations by
    LCD-text disallowed reasons. Hence the histogram value for each reason is
    the approximate number of non-LCD kilo-pixels resulting from that reason.
    Recorded when the renderer is idle, at minimum interval of the longer of 1
    minute and 500 begin frames for each local frame tree.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.LCDTextDisallowedReasonLayers"
    enum="LCDTextDisallowedReason" expires_after="2022-12-18">
  <owner>wangxianzhu@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    Records the number of layers containing text by LCD-text disallowed reasons.
    Recorded along with Compositing.Renderer.LCDTextDisallowedReasonKPixels.
  </summary>
</histogram>

<histogram name="Compositing.Renderer.NumActiveLayers" units="layers"
    expires_after="2023-04-23">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of layers in the active tree for each compositor frame. This is
    logged once per frame, before the frame is drawn (in a renderer process).
  </summary>
</histogram>

<histogram name="Compositing.Renderer.NumActivePictureLayers" units="layers"
    expires_after="2023-04-23">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of PictureLayers in the active tree for each compositor frame.
    This is logged once per frame, before the frame is drawn (in a renderer
    process).
  </summary>
</histogram>

<histogram name="Compositing.Renderer.NumRenderSurfaces" units="surfaces"
    expires_after="2023-01-01">
  <owner>schenney@chromium.org</owner>
  <owner>paint-dev@chromium.org</owner>
  <summary>
    The number of render surfaces in the render surface layer list. Recorded
    each time the render surface layer list is constructed (in a renderer
    process).
  </summary>
</histogram>

<histogram name="Compositing.SkiaRenderer.DirectlyDrawableRenderPassWithRPDQ"
    units="boolean" expires_after="2023-04-01">
  <owner>khushalsagar@chromium.org</owner>
  <owner>vmpstr@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Logged for every nested RenderPass to indicate whether it could have been
    drawn directly because it has a single RPDQ and no other effect which would
    require producing a render pass.
  </summary>
</histogram>

<histogram name="Compositing.SkiaRenderer.DrawTileDrawQuad.UsingRawDraw"
    units="boolean" expires_after="2023-04-09">
  <owner>backer@chromium.org</owner>
  <owner>penghuang@chromium.org</owner>
  <summary>Records if the TileDrawQuad is rendered with RawDraw.</summary>
</histogram>

<histogram name="Compositing.SkiaRenderer.SkipOverlayRenderPassDrawQuad"
    enum="BooleanSkipped" expires_after="2023-04-01">
  <owner>magchen@chromium.org</owner>
  <owner>ccameron@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Logged for every RenderPassDrawQuad in the overlay list during
    ScheduleOverlays. An Overlay RenderPassDrawQuad is skipped if there is no
    damages to the render pass and the RenderPassDrawQuad settings are the same.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.AggregateUs"
    units="microseconds" expires_after="2023-04-30">
  <owner>kylechar@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Time spent aggregating compositor frames from different surfaces in
    microseconds. This is logged once per frame.

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.CopiedSurfaceCount"
    units="surfaces" expires_after="2023-03-19">
  <owner>kylechar@chromium.org</owner>
  <owner>jonross@chromium.org</owner>
  <summary>
    The number of surfaces where the active CompositorFrame was copied into the
    AggregateFrame during surface aggregation. This is logged once per frame.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.CopyUs" units="microseconds"
    expires_after="2023-04-30">
  <owner>kylechar@chromium.org</owner>
  <owner>jonross@chromium.org</owner>
  <summary>
    Time spent copying quads during surface aggregation. This is a subset of the
    time recorded for Compositing.SurfaceAggregator.AggregateUs and is logged
    once per frame.

    Warning: This metric does not include reports from clients with
    low-resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.DeclareResourcesUs"
    units="microseconds" expires_after="2023-04-16">
  <owner>kylechar@chromium.org</owner>
  <owner>jonross@chromium.org</owner>
  <summary>
    Time spent declaring resources as used during surface aggregation. This is a
    subset of the time recorded for Compositing.SurfaceAggregator.AggregateUs
    and is logged once per frame.

    Warning: This metric does not include reports from clients with
    low-resolution clocks.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.PrewalkedSurfaceCount"
    units="surfaces" expires_after="2023-04-16">
  <owner>kylechar@chromium.org</owner>
  <owner>jonross@chromium.org</owner>
  <summary>
    The number of surfaces that were looked at during the prewalk phase of
    surface aggregation. This is logged once per frame.
  </summary>
</histogram>

<histogram name="Compositing.SurfaceAggregator.PrewalkUs" units="microseconds"
    expires_after="2023-04-16">
  <owner>kylechar@chromium.org</owner>
  <owner>jonross@chromium.org</owner>
  <summary>
    Time spent doing prewalk during surface aggregation. This is a subset of the
    time recorded for Compositing.SurfaceAggregator.AggregateUs and is logged
    once per frame.

    Warning: This metric does not include reports from clients with
    low-resolution clocks.
  </summary>
</histogram>

<histogram
    name="CompositorLatency.CompositorOnlyFrame{InteractionType}.{StageType}"
    units="microseconds" expires_after="2023-03-01">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the duration of various stages in the pipeline as a single frame goes
    through the various stages in the compositor in the cases that there is no
    damage from main thread.

    This metric uses base::Histogram::FactoryMicrosecondsTimeGet so only users
    with high resolution clocks will report this metric.
  </summary>
  <token key="InteractionType">
    <variant name=""/>
    <variant name=".CanvasAnimation"/>
    <variant name=".CompositorAnimation"/>
    <variant name=".JSAnimation"/>
    <variant name=".MainThreadAnimation"/>
    <variant name=".PinchZoom"/>
    <variant name=".RAF"/>
    <variant name=".ScrollbarScroll"/>
    <variant name=".SETCompositorAnimation"/>
    <variant name=".SETMainThreadAnimation"/>
    <variant name=".TouchScroll"/>
    <variant name=".WheelScroll"/>
  </token>
  <token key="StageType">
    <variant name="BeginImplFrameToFinishImpl"/>
    <variant name="ImplFrameDoneToSubmitCompositorFrame"/>
    <variant name="SendBeginMainFrameToBeginMainAbort"/>
    <variant name="SubmitCompositorFrameToPresentationCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.BufferAvailableToBufferReady"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.BufferReadyToLatch"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.LatchToSwapEnd"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.ReceivedCompositorFrameToStartDraw"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.StartDrawToSwapStart"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SubmitToReceiveCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapEndToPresentationCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapStartToBufferAvailable"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapStartToSwapEnd"/>
    <variant name="TotalLatency"/>
  </token>
</histogram>

<histogram name="CompositorLatency.Type" enum="FrameReportType"
    expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Whether frame is dropped or presented meeting or missing the deadline or is
    a compositor only frame.
  </summary>
</histogram>

<histogram name="CompositorLatency{ReportType}{InteractionType}.{StageType}"
    units="microseconds" expires_after="2023-07-24">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the duration of various stages in the pipeline as a single frame goes
    through the various stages in the compositor {ReportType}.

    This metric uses base::Histogram::FactoryMicrosecondsTimeGet so only users
    with high resolution clocks will report this metric.
  </summary>
  <token key="ReportType">
    <variant name=""
        summary="reported for frames that went through all the compositor
                 stages in chromium, and was presented to the user"/>
    <variant name=".DroppedFrame"
        summary="reported for frames that the user did not see: this includes
                 frames that are dropped in various stages inside chromium,
                 or even frames that went through all stages in chromium, but
                 ultimately was not presented to the user"/>
    <variant name=".MissedDeadlineFrame"
        summary="reported for frames that went through all the compositor
                 stages in chromium, and was presented to the user, but were
                 delayed and missed their deadline"/>
  </token>
  <token key="InteractionType">
    <variant name=""/>
    <variant name=".CanvasAnimation"/>
    <variant name=".CompositorAnimation"/>
    <variant name=".JSAnimation"/>
    <variant name=".MainThreadAnimation"/>
    <variant name=".PinchZoom"/>
    <variant name=".RAF"/>
    <variant name=".ScrollbarScroll"/>
    <variant name=".SETCompositorAnimation"/>
    <variant name=".SETMainThreadAnimation"/>
    <variant name=".TouchScroll"/>
    <variant name=".WheelScroll"/>
  </token>
  <token key="StageType">
    <variant name="Activation"/>
    <variant name="BeginImplFrameToSendBeginMainFrame"/>
    <variant name="Commit"/>
    <variant name="EndActivateToSubmitCompositorFrame"/>
    <variant name="EndCommitToActivation"/>
    <variant name="SendBeginMainFrameToCommit"/>
    <variant name="SendBeginMainFrameToCommit.Animate"/>
    <variant name="SendBeginMainFrameToCommit.BeginMainSentToStarted"/>
    <variant name="SendBeginMainFrameToCommit.CompositeCommit"/>
    <variant name="SendBeginMainFrameToCommit.CompositingInputs"/>
    <variant name="SendBeginMainFrameToCommit.HandleInputEvents"/>
    <variant name="SendBeginMainFrameToCommit.LayoutUpdate"/>
    <variant name="SendBeginMainFrameToCommit.Paint"/>
    <variant name="SendBeginMainFrameToCommit.Prepaint"/>
    <variant name="SendBeginMainFrameToCommit.StyleUpdate"/>
    <variant name="SendBeginMainFrameToCommit.UpdateLayers"/>
    <variant name="SubmitCompositorFrameToPresentationCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.BufferAvailableToBufferReady"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.BufferReadyToLatch"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.LatchToSwapEnd"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.ReceivedCompositorFrameToStartDraw"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.StartDrawToSwapStart"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SubmitToReceiveCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapEndToPresentationCompositorFrame"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapStartToBufferAvailable"/>
    <variant
        name="SubmitCompositorFrameToPresentationCompositorFrame.SwapStartToSwapEnd"/>
    <variant name="TotalLatency"/>
  </token>
</histogram>

<histogram name="Graphics.Smoothness.95pctPercentDroppedFrames_1sWindow"
    units="%" expires_after="2023-04-30">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    The percent dropped frame is calculated for each sliding window of 1 second
    length and added to a histogram, and then the 95 percentile of that
    histogram is reported as 95pctPercentDroppedFrames_1sWindow.

    The sliding windows cover the duration of page-load (From start of page-load
    until user navigates away, or closes the tab/chrome, or when app goes to
    background). Note that this means that this metric will bias toward tabs
    that are closed more quickly, and might underreport tabs that remain open
    for a long duration.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.Checkerboarding" units="%"
    expires_after="2023-04-16">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of frames that were shown with checkerboards during a
    particular sequence of frames (e.g. during scroll, animation, etc.). Note
    that this is only recorded for sequences of length > 4.

    Checkerboarding is measured by tracking the number of times checkerboard
    frames are displayed (as opposed to the number of checkerboard frames
    produced), since the same checkerboard frame can be displayed more than
    once.
  </summary>
</histogram>

<histogram
    name="Graphics.Smoothness.Diagnostic.DroppedFrameAfterScrollStart2.Frames"
    units="vsyncs" expires_after="2023-02-12">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Diagnostic metric to measure how long after scroll-start a frame is dropped.

    For every frame dropped during a scroll, this metric reports how long after
    scroll started the frame dropped (in number of vsyncs).
  </summary>
</histogram>

<histogram
    name="Graphics.Smoothness.Diagnostic.DroppedFrameAfterScrollStart2.Time"
    units="ms" expires_after="2023-02-12">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Diagnostic metric to measure how long after scroll-start a frame is dropped.

    For every frame dropped during a scroll, this metric reports how long after
    scroll started the frame dropped (in milliseconds).
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.Jank" units="%" expires_after="2023-06-01">
  <owner>jonross@chromium.org</owner>
  <owner>mjzhang@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of janks for a particular sequence of frames (e.g. during
    scroll, animation, etc.). This is reported in various sub-metrics with
    suffixes describing the type of the sequence (e.g. TouchScroll etc.).

    Jank is measured by tracking the number of abrupt increases in frame
    presentation interval, divided by the total number of frames expected to be
    produced and displayed. The lower this number is, the less the smoothness
    varies over time.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.Jank.All{Type}" units="%"
    expires_after="2023-06-01">
  <owner>jonross@chromium.org</owner>
  <owner>mjzhang@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of janks for a particular frame sequence. {Type}

    Jank is measured by tracking the number of abrupt increases in frame
    presentation interval, divided by the total number of frames expected to be
    produced and displayed. The lower this number is, the less the smoothness
    varies over time.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
  <token key="Type">
    <variant name="Animations"
        summary="This metric aggregates data reported from all types of
                 animations (e.g. comositor-driven animations, main-thread
                 driven animations, and raf-driven animations, etc.)."/>
    <variant name="Interactions"
        summary="This metric aggregates data reported for all supported
                 combinations of interaction types (e.g. scrolling, pinching,
                 etc.) and input device types (e.g. touchscreen, touchpad,
                 mousewheel, etc.)."/>
    <variant name="Sequences"
        summary="This metric aggregates data from all animations and all
                 interactions."/>
  </token>
</histogram>

<histogram name="Graphics.Smoothness.MaxPercentDroppedFrames_1sWindow"
    units="%" expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for in a 1 second sliding window.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.MaxStale" units="ms"
    expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>mjzhang@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the maximum staleness value for all presentations for a particular
    sequence of frames (e.g. during scroll, animation, etc.). This is reported
    in various sub-metrics with suffixes describing the type of the sequence
    (e.g. TouchScroll etc.).

    Typically, a frame presentation is expected to last at least one vsync
    cycle, plus any number of additional vsync cycles if no updates are expected
    duration that time. If the presentation interval is prolonged due to reasons
    other than listed above, then that prolonged portion will be considered
    staleness for that frame.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames" units="%"
    expires_after="2023-02-19">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a particular sequence of frames
    (e.g. during scroll, animation, etc.). This is reported in various
    sub-metrics with suffixes describing the type of the sequence (e.g.
    TouchScroll etc.).

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames.AllAnimations"
    units="%" expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a particular sequence of frames for
    all animations. This metric is reported for all animations (e.g.
    comositor-driven animations, main-thread driven animations, and raf-driven
    animations).

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames.AllInteractions"
    units="%" expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a particular sequence of frames
    where a user-input (e.g. scroll, pinch) is active. This metric is reported
    for all sources of user-input (i.e. both touchscreen and
    touchpad/mouse-wheel).

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames.AllSequences"
    units="%" expires_after="2023-04-23">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a particular sequence of frames.
    This metric is reported for all animations and all interactions.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames2.{Thread}{Sequence}"
    units="%" expires_after="2023-03-07">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a particular sequence of frames.
    This metric aggregates data {Sequence}

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.

    This is a new implementation of the older
    Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric.
  </summary>
  <token key="Thread">
    <variant name=""/>
    <variant name="CompositorThread."/>
    <variant name="MainThread."/>
  </token>
  <token key="Sequence">
    <variant name="AllAnimations"
        summary="reported from all types of animations (e.g. comositor-driven
                 animations, main-thread driven animations, and raf-driven
                 animations, etc.)."/>
    <variant name="AllInteractions"
        summary="reported for all supported combinations of interaction types
                 (e.g. scrolling, pinching, etc.) and input device types
                 (e.g. touchscreen, touchpad, mousewheel, etc.)."/>
    <variant name="AllSequences"
        summary="from all animations and all interactions."/>
    <variant name="CanvasAnimation"
        summary="reported for all canvas animations."/>
    <variant name="CompositorAnimation"
        summary="reported for all compositor thread driven animations."/>
    <variant name="JSAnimation"
        summary="reported for all JS driven animations."/>
    <variant name="MainThreadAnimation"
        summary="reported for all main thread driven animations."/>
    <variant name="PinchZoom"
        summary="reported for all pinch to zoom interctions."/>
    <variant name="RAF" summary="reported for all raf driven animations."/>
    <variant name="ScrollbarScroll"
        summary="reported for all scrollbar scrolling."/>
    <variant name="SETCompositorAnimation"
        summary="reported for all compositor animations during a shared
                 element transition"/>
    <variant name="SETMainThreadAnimation"
        summary="reported for all main thread animations during a shared
                 element transition"/>
    <variant name="TouchScroll" summary="reported for all touch scrolling."/>
    <variant name="WheelScroll" summary="reported for all wheel scrolling."/>
  </token>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames3.AllSequences"
    units="%" expires_after="never">
<!-- expires-never: guiding metric (internal: go/chrome-browser-guiding-metrics) -->

  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <owner>chrome-analysis-team@google.com</owner>
  <summary>
    Tracks the percent of dropped frames for a sequence by aggregating all its
    animations and interactions, where a sequence is a series of frames produced
    which contain at least one of the animations/interactions. Such animations
    and interactions encompass: Compositor-thread animations; Main-thread
    animations; JS animations; scrolling; and pinch-gestures.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother the experience.

    Note that this metric is reported only when there are a sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until an additional sequence completes where there are (>=
    100) frames available in total.

    This is a new implementation of the older
    Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric.

    This histogram is of special interest to the chrome-analysis-team@. Do not
    change its semantics or retire it without talking to them first.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentDroppedFrames3.{Thread}{Sequence}"
    units="%" expires_after="2023-05-11">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of dropped frames for a sequence by aggregating all
    {Sequence}, where a sequence is a series of frames produced which contain at
    least one of the aforementioned effects.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother the experience.

    Note that this metric is reported only when there are a sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until an additional sequence completes where there are (>=
    100) frames available in total.

    This is a new implementation of the older
    Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric.
  </summary>
  <token key="Thread">
    <variant name=""/>
    <variant name="CompositorThread."/>
    <variant name="MainThread."/>
  </token>
  <token key="Sequence">
    <variant name="AllAnimations"
        summary="its animations (e.g. comositor-driven animations,
                 main-thread driven animations, and raf-driven animations,
                 etc.)"/>
    <variant name="AllInteractions"
        summary="its supported combinations of interaction types (e.g.
                 scrolling, pinching, etc.) and input device types (e.g.
                 touchscreen, touchpad, mousewheel, etc.)"/>
    <variant name="CanvasAnimation" summary="canvas animations"/>
    <variant name="CompositorAnimation"
        summary="compositor thread driven animations"/>
    <variant name="JSAnimation" summary="JS driven animations"/>
    <variant name="MainThreadAnimation"
        summary="main thread driven animations"/>
    <variant name="PinchZoom" summary="pinch to zoom interctions"/>
    <variant name="RAF" summary="raf driven animations"/>
    <variant name="ScrollbarScroll" summary="scrollbar scrolling"/>
    <variant name="SETCompositorAnimation"
        summary="compositor animations during a view transition"/>
    <variant name="SETMainThreadAnimation"
        summary="main thread animations during a view transition"/>
    <variant name="TouchScroll" summary="touch scrolling"/>
    <variant name="WheelScroll" summary="wheel scrolling"/>
  </token>
</histogram>

<histogram base="true" name="Graphics.Smoothness.PercentMissedDeadlineFrames"
    units="%" expires_after="2022-09-30">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of frames that missed the deadline for a particular
    sequence of frames (e.g. during scroll, animation, etc.). This is reported
    in various sub-metrics with suffixes describing the type of the sequence
    (e.g. TouchScroll etc.).

    PercentMissedDeadlineFrames is measured by tracking the number of frames
    which were displayed on screen but missed the vsync interval.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentMissedDeadlineFrames.AllAnimations"
    units="%" expires_after="2022-09-30">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of frames that missed the deadline for a particular
    sequence of frames for all animations. This metric is reported for all
    animations (e.g. comositor-driven animations, main-thread driven animations,
    and raf-driven animations).

    PercentMissedDeadlineFrames is measured by tracking the number of frames
    which were displayed on screen but missed the vsync interval.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram
    name="Graphics.Smoothness.PercentMissedDeadlineFrames.AllInteractions"
    units="%" expires_after="2022-09-30">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of frames that missed the deadline for a particular
    sequence of frames where a user-input (e.g. scroll, pinch) is active. This
    metric is reported for all sources of user-input (i.e. both touchscreen and
    touchpad/mouse-wheel).

    PercentMissedDeadlineFrames is measured by tracking the number of frames
    which were displayed on screen but missed the vsync interval.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.PercentMissedDeadlineFrames.AllSequences"
    units="%" expires_after="2023-04-16">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the percent of frames that missed the deadline for a particular
    sequence of frames. This metric is reported for all animations and all
    interactions.

    PercentMissedDeadlineFrames is measured by tracking the number of frames
    which were displayed on screen but missed the vsync interval.

    Note that this metric is reported only when there are sufficient number of
    frames (>= 100). If there are sequences with fewer frames, then these are
    aggregated until there are enough frames to produce the metric.
  </summary>
</histogram>

<histogram
    name="Graphics.Smoothness.PerSession.95pctPercentDroppedFrames_1sWindow"
    units="%" expires_after="2023-04-17">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the 95th percentile of dropped frames percent of a sliding window of
    1 second. The metric is reported once per page-load when the page closes. If
    there are fewer than 20 sliding windows for calculating 95th percentile, the
    max value will be used instead of 95th percentile.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.
  </summary>
</histogram>

<histogram
    name="Graphics.Smoothness.PerSession.MaxPercentDroppedFrames_1sWindow"
    units="%" expires_after="2023-04-09">
  <owner>jonross@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the Max of dropped frames percent of a sliding window of 1 second.
    The metric is reported once per page-load when the page closes.

    PercentDroppedFrames is measured by tracking the number of frames which were
    not displayed on screen out of the total number of frames expected to be
    produced and displayed. In other words, the lower this number is, the
    smoother experience.
  </summary>
</histogram>

<histogram name="Graphics.Smoothness.Stale" units="ms"
    expires_after="2022-12-18">
  <owner>jonross@chromium.org</owner>
  <owner>mjzhang@chromium.org</owner>
  <owner>graphics-dev@chromium.org</owner>
  <summary>
    Tracks the staleness value for each frame presentation for a particular
    sequence of frames (e.g. during scroll, animation, etc.). This is reported
    in various sub-metrics with suffixes describing the type of the sequence
    (e.g. TouchScroll etc.).

    Typically, a frame presentation is expected to last at least one vsync
    cycle, plus any number of additional vsync cycles if no updates are expected
    duration that time. If the presentation interval is prolonged due to reasons
    other than listed above, then that prolonged portion will be considered
    staleness.

    Note that the reporting of this metric occurs as soon as a frame is
    presented, and is not affected by the length of the frame sequence.
  </summary>
</histogram>

</histograms>

</histogram-configuration>

redpajama_set_name: RedPajamaGithub


Det er fantastisk å være tilbake, sier Vårt Lands nye sjefredaktør Åshild Mathisen.
Clothes should be comfortable for you to wear on your first date.They should define your classy side. No I am not saying wear a cheap ralph lauren suit or dress clothes. I am saying wear something that you would wear to impress the person of your dreams. No khakis should be worn on dates, because khakis are professional. Most of the time professional and classy gets mixed to together. Lets just think about a buttoned up shirt long or short sleeves. If that does not work for you, lets think about denim button up shirts. These cheap christian louboutin shoes are comfortable for every date for every type of person. They are easy to match and blend with. Something that is easy to match with and very clean looking.What makes you classy is that your jeans fit you, by that I mean not baggy. I personally do not shop for name branded clothing.
cheap ralph lauren t-shirts on sale,discount polo ralph lauren for men outlet in ralph lauren uk sale online store,buy ralph lauren big pony polos with great discount.
Where can I buy the real cheap viagra or generic cialis for non prescription?


text:
PCMag Asia Computers & Electronics Networking
No, Samsung Didn't Invent High-Speed 60GHz Wi-Fi
Samsung issues a clever, yet somewhat misleading press release.
By Samara Lynn
Samsung's announcement that it has developed 60GHz Wi-Fi technology that provide speeds up to 4.6Gbps is causing some confusion. Let's be clear up front: Samsung did not just invent 60GHz Wi-Fi nor does it make home wireless routers.
High-speed Wi-Fi, known as WiGig is a wireless networking standard, named 802.11ad. I spoke with the Wi-Fi Alliance's VP of Marketing, Kelly Davis-Felner, back in 2011 when the IEEE and the Wi-Fi Alliance started releasing details about 802.11ac and 11ad. At the time, Davis-Felner explained that WiGig is not really a standard that would be added into wireless routers.
Instead, 802.11ad is a wireless networking standard that uses the 60GHz frequency and is for high-speed communications between devices within a wireless network. For example, consumers can have an "island" of WiGig that operates at the 60 GHz band and can be dedicated for high-quality video and audio streaming or transmitting high performance wireless data. From the Wi-Fi Alliance's site: "Popular use cases for WiGig include cable replacement for display extensions, wireless docking between devices like laptops and tablet, instant sync and backup and simultaneous streaming of multiple, ultra-high definition and 4K videos."
But now we have this press release from Samsung which sounds as though the company has revolutionized Wi-Fi as we know it. However, take a closer look at the statement and you will see carefully worded phrases such as, "its 60GHz Wi-Fi technology" and "Samsung's 802.11ad standard 60GHz Wi-Fi technology." While Samsung did not release specifics, the wording of the press release leads me to believe that Samsung will release devices that have proprietary WiGig capability only for Samsung device connectivity. These devices will create that "island" of WiGig that Davis-Felner spoke of three years ago.
We know that Samsung does not make wireless routers for consumers (it has manufactured a few for enterprise customers, but not many). Samsung makes smart TVs, tablets, and monitors, and mostly other end-user devices. In all probability, these Samsung devices will be able to network with one another to increase internal throughput from one Samsung device to another. This isn't a technology that will replace a wireless router for connecting non-Samsung products.
I read with some amusement reports that stated that Samsung "made" a new kind of Wi-Fi. That is not the case here. Samsung customized 802.11ad technology for its products. The details about beamforming and lessing interference in the announcement sound intriguing. Samsung may not have invented WiGig, but it looks like the company found a way to optimize it in its products.
SpaceX Sidesteps Amazon Spat, Eyes March Launch for 2nd-Gen Starlink Satellites
Starlink Deliveries Slow Amid Chip Shortage, FedEx Delays
Verizon, AT&T Delay Expanded 5G Rollout for 2 Weeks
How to Turn on Your Computer From Across the House With Wake-on-LAN
About Samara Lynn
Samara Lynn has nearly twenty years experience in Information Technology; most recently as IT Director at a major New York City healthcare facility. She has a Bachelor's degree from Brooklyn College, several technology certifications, and she was a tech editor for the CRN Test Center.
With an extensive, hands-on background in deploying and managing Microsoft Windows infrastructures and networking, she was included in Black Enterprise's "20 Black Women in Tech You Need to Follow on Twitter," and received the 2013 Small Business Influencer Top 100 Champions award. Lynn is the author of Windows Server 2012: Up and Running, published by O'Reilly.
An avid Xbox gamer, she unashamedly admits to owning …
More From Samara Lynn
Totolink A2004NS AC1200 Wireless Dual Band Gigabit Router with USB Port
D-Link Wireless AC1900 Dual-Band Gigabit Cloud Router (DIR-880L) Review
Netgear Nighthawk X4 AC2350 Smart WiFi Router (R7500) Review
D-Link WiFi AC750 Portable Router and Charger (DIR-510L).

redpajama_set_name: RedPajamaCommonCrawl


text:
Runaway, skriven av Pearu Paulus, Ilmar Laisaar, Jana Hallas och Alar Kotkas, är en sång som Sahlene framförde för Estland i Eurovision Song Contest 2002, där melodin slutade på tredje plats. Sången blev samma år en stor hit i Sverige, där den som bäst nådde tjugonde platsen på singellistan.

Sången handlar om kärlek, där sångens jag-person talar om för den som denne älskar att tänka på nya möjligheter, och inte bara leva som tidigare.

Listplaceringar

Referenser

Fotnoter

Bidrag till Eurovision Song Contest 2002
Estlands bidrag i Eurovision Song Contest
Musiksinglar 2002
Engelskspråkiga sånger

redpajama_set_name: RedPajamaWikipedia


text:
Deeplinks Blog by rainey Reitman | June 7, 2012
The Cybersecurity Act (S. 2105) Threatens Online Rights - a Handout for Your Senator
Worried about the Lieberman-Collins Cybersecurity Act? You should be. As we've explained before, it poses serious threats to online rights. Here's a one-page handout you can use as a reference. It's great for sharing with friends, handing to Senate staffers, publishing online, or using as talking points when...
Read more about The Cybersecurity Act (S. 2105) Threatens Online Rights - a Handout for Your Senator
Deeplinks Blog by Kurt Opsahl, rainey Reitman | May 31, 2012
Frequently Asked Questions About the Lieberman-Collins Cyber Security Act
The Senate is moving quickly to take up the issue of cybersecurity, with a potential vote looming in early June. This is a particularly dangerous situation because the Cyber Intelligence Sharing and Protection Act (CISPA) already passed the House, authorizing companies to spy on sensitive user content and pass that...
Read more about Frequently Asked Questions About the Lieberman-Collins Cyber Security Act
Deeplinks Blog by rainey Reitman | May 24, 2012
Call to Action: Join the Fight Against Cyber Spying Proposals in the Senate
EFF and an array of civil liberties organizations are engaged in a pitched battle against the privacy-invasive legislation Congress is pushing under the guise of promoting "cyber security." Everyone agrees that network security is important, but a thinly disguised mass surveillance bill won't help address the needs of our country...
Read more about Call to Action: Join the Fight Against Cyber Spying Proposals in the Senate
With New Privacy Policy, Twitter Commits to Respecting Do Not Track
Under a new policy announced today, Twitter will be suggesting accounts for Twitter users to follow based on data collected from an individual's browsing habits on websites that have embedded Twitter buttons. While this is sure to garner scrutiny from the press and public, Twitter is also taking...
Read more about With New Privacy Policy, Twitter Commits to Respecting Do Not Track
Deeplinks Blog by rainey Reitman | April 26, 2012
EFF Condemns CISPA, Vows to Take Fight to the Senate
Hours ago, the House of Representatives voted to approve the Cyber Intelligence Sharing and Protection Act (CISPA), a bill that would allow companies to bypass all existing privacy law to spy on communications and pass sensitive user data to the government. EFF condemns the vote in...
Read more about EFF Condemns CISPA, Vows to Take Fight to the Senate
Even with Rogers' Amendments, CISPA is Still a Surveillance Bill
This week, a flurry of amendments were introduced to try to salvage the Cyber Information Sharing and Protection Act (CISPA), a "cybersecurity" bill moving through the house that's been criticized as giving companies free rein to spy on personal communications and pass unredacted content (like emails) to the...
Read more about Even with Rogers' Amendments, CISPA is Still a Surveillance Bill
The NSA in Your Inbox? No Way. Call Now to Stop CISPA
The House of Representatives is now poised to vote on the Cyber Intelligence Sharing and Protection Act (CISPA), which would allow companies to monitor our online communications and share private information about users with the government.
CISPA would let companies bypass all existing privacy law as long as...
Read more about The NSA in Your Inbox? No Way. Call Now to Stop CISPA
Opposition to CISPA Increases: Free Market Coalition and Ron Paul Come Out Against Bill
The recent Week of Action against CISPA, the dangerously vague 'cybersecurity' bill , highlights the growing bi-partisan disapproval of the many provisions that would gut all existing privacy laws. Internet users across the political spectrum voiced their concerns with how the bill allows companies...
Read more about Opposition to CISPA Increases: Free Market Coalition and Ron Paul Come Out Against Bill
Deeplinks Blog by Micah Lee, rainey Reitman | April 19, 2012
Embeddable Version of Congressional Twitter Handle Detection Tool Now Available
On Monday, EFF launched our Stop Cyber Spying platform featuring our new Congressional Twitter Handle Detection Tool. Users can enter a zip code in order to find their Representative's Twitter account. Folks are then urged to tweet messages to their Representatives highlighting the invasive nature of the CISPA...
Read more about Embeddable Version of Congressional Twitter Handle Detection Tool Now Available
Internet to Congress: CISPA is TMI
Yesterday, EFF and other civil liberties organizations launched a campaign to change the public discussion around the Cyber Intelligence Sharing and Protection Act (CISPA), a cybersecurity bill introduced by Rep. Mike Rogers (R-MI) and Dutch Ruppersberger (D-MD) (H.R. 3523). The bill would carve out huge exemptions to...
Read more about Internet to Congress: CISPA is TMI


Before my first adventure, I thought I needed to buy all the things. My bank account, however, thought differently. Several years of travel experience later, I realized many things wrong with this belief.
Specialized travel gear is expensive. I want a lot of new gear, but my budget rarely allows for these splurges in addition to flights, accommodation, etc. That's all travel gear is, though–splurges. I'd rather one more adventure instead of one more pair of boots. While specific adventures may require specialized gear–such as a tent for camping or fins for diving–most of the time you can get by with what you already own.
Travel requires minimalism. You'll have one, maybe two, bags to lug around the world. I don't understand how travel bloggers pack everything in their packing guides into one, maybe two, bags. These lists are frequently excessive and impractical. Besides, you are in the country to adventure, experience discomfort, and live the local culture. Very few items are absolutely essential to accomplish these goals.
Buying things is bad for the environment. Everything requires Earth's limited resources to produce. One flaw I find in the travel blogging community, and with society in general, is the push to buy buy buy. Whether it's a sales tactic or to display wealth, our society is obsessed with buying stuff.
My workout clothes and running shoes were good enough for this day hike. No special gear necessary!
Don't let not having "the right stuff" prevent you from exploring the world. I promise you'll be okay without the latest portable charger or packing cube.
Look, I realize the hypocrisy in me mentioning all this since I advertise several products on this blog and flying is not the most eco-friendly transportation method.
Who knew a headband borrowed from a friend and an old t-shirt with paint splatters on the front could have this much aesthetic?
I promise to be transparent with the essentialness of everything I promote on this platform. As my financial freedom increases from growth of my personal career and Getaway Girl, I will buy more travel gear (some of it superfluous). I want to share my experience with these products with you, but I will indicate how essential the product/service is and if there are alternatives to the products.
All products on this blog I use and love in my daily life. No really. In fact, I will show you products I love even if I don't get money from it. Your loyalty to Getaway Girl means the world to me so I promise to be selective with partnerships. I will only advertise products and services I love and I know you will love too. This travel blog will never become suddenly obsessed with a particular product because they gave me some money.
Most importantly, I encourage you to shop consciously. I suggest you wait about 30 days before purchasing anything. Consider if there are alternatives during this time, such as if you could borrow it from a friend or if there are DIY options or alternatives already at home. If after 30 days you still want or need it, shop secondhand or find a conscious producer of the product. Try to buy products with multiple uses or made of long-lasting, eco-friendly materials.
Affiliate advertising (aka, when you click a link to a product on this website it will sometimes give me a small commission at no additional cost to you) helps keep Getaway Girl running. When you purchase something, please consider purchasing via Getaway Girl.
Finally, this community is for you and your support and feedback means the world to me. If you ever have a suggestion to improve Getaway Girl and our product promotion philosophy, please contact me via email at hello@getawaygirl.us.


text:
What Is a Beacon, Anyway?
By Emily Reynolds
In Blog Articles, Location-Based Services, Mobile Engagement
What Is a Beacon, Anyway?2014-10-072018-07-03https://www.phunware.com/wp-content/themes/jupiter-child/images/pw-logo.svgPhunwarehttps://www.phunware.com/wp-content/uploads/2014/10/blog-whatsabeacon_d3.png200px200px
Beacons play an important role in mobile location detection.
When you think of a beacon, what comes to mind? A fire on a remote mountain? A blinking light at the top of a building? A lighthouse? Just like these traditional beacons, wireless beacons are designed to communicate an important message to everyone within a certain proximity.
Beacons are small Bluetooth-enabled devices that transmit a continuous signal. The signal is "heard" by devices within a certain distance (from a few inches up to about a hundred feet) from the beacon. If a device has the relevant app installed when it recognizes the beacon, it will begin to communicate with the server to "ask" if it has any relevant information to share.
Many companies today are using this location awareness as an opportunity to send contextually relevant push notifications to users' devices—things like special offers, reminder and welcome messages, and other alerts.
In other words, beacons help people connect in context. Learn more in our on-demand webinar, Mobile at the Intersection of Hardware and Software.
What Role Do Beacons Play in the Network?
Beacons are invaluable tools for mobile interaction, but they are only one element in the location technology universe. It's important to understand the role of the different location technologies, and where beacons fit in.
GPS is accurate, but because it depends on satellite communication, it doesn't work well inside a building or anywhere without a clear line of sight to the sky. Additionally, because GPS location detection is persistent, it can increase the load on network traffic and drain the battery of a mobile device.
Wi-Fi networks can be very precise at location detection, especially with multiple routers and add-on software to triangulate their signals—essentially turning the Wi-Fi network into a mini-GPS. Unfortunately, Wi-Fi users are required to consent to network connection, which adds an additional step to the interaction and may reduce the frequency of engagement.
Beacons provide the greatest accuracy; and with the introduction of Bluetooth Low Energy technology (BLE), beacons can be deployed almost anywhere. Whereas once the battery consumption of Bluetooth technology limited its applications, the advent of BLE has opened up a new world of location-enabled possibilities.
Learn more in this eBook: Location Technology 101: Understanding Bluetooth, Blue Dot, Beacons, Geo-Fencing and More.
Each BLE beacon has a very small footprint and is designed to operate for years on standard coin cell batteries. BLE also supports enhanced range capability of up to 200 feet. Beacons are not only easy to deploy—the fact that they only interact with in-range mobile devices limits costly network traffic and reduces the drain on mobile battery life. Recently, the introduction of virtual Bluetooth beacons has made beacon management and maintenance even easier. Learn more in The No-Geek-Speak Lowdown on Virtual Beacons.
Beacons Help Drive User Engagement
Beacons enable businesses to engage users in real time, a practice that has been shown to deliver a 45 percent interaction rate (five times higher than that of traditional push messages).1
Retail locations use beacons to provide their most loyal customers (those with the store's app on their smartphones) with customized offers while they are in the store. Beacons placed in a certain department or on a certain display can be detected by in-range mobile devices, and thereby trigger a message containing a coupon, special offer or additional product information.
Schools can use beacons to keep track of district-owned mobile devices. If a student moves a device beyond a specific threshold, like a classroom door, an alert can be triggered.
Similarly, hospitals can use beacons for asset tracking, thereby reducing time spent hunting down pieces of equipment (not to mention theft and loss). Learn about more powerful healthcare use cases in this on-demand webinar: Using New Technologies to Enhance Patient Satisfaction.
Anyone in a large building or campus environment—hospitals, universities, municipalities and businesses—can use beacons to help people find points of interest or to trigger "you are here" notifications in a wayfinding application.
Beacons Deliver Valuable Interactions
Although they are relatively small and simple, beacons are powerful technology that can enable groundbreaking use cases. For more information about how enterprises across industries are using mobile software and location-enabled hardware to enhance the customer experience, download our on-demand webinar: Mobile at the Intersection of Hardware and Software.
1PR Newswire. (2014) inMarket: Beacons Done Right Increase Interactions by 5x; Beacons Done Wrong Lead to App Deletion. Retrieved October 1, 2014
What Is a Beacon, Anyway? was last modified: July 3rd, 2018 by Emily Reynolds
Location-Based Services Mobile Engagement
Emily Reynolds
Emily was formerly the Senior Director of Marketing at Phunware. She's a weird cat person and a glutton for Mexican food. Follow her on Twitter at @EmJReynolds.
Dell Announces Fall Class of Founders 50Blog Articles
11 Steps to Getting More Money Out of Your Mobile AppAudience Monetization, Blog Articles


text:
Vine moves beyond Twitter with new embed feature
Twitter's mobile video app now lets users post anywhere on the web
Zach Miners (IDG News Service) 29 March, 2013 20:23
Vine's branching out. Videos made with the trendy Twitter-owned mobile app can now be posted anywhere on the Web.
Previously, Vine posts could only be shared within users' networks on Vine itself as well as on Twitter and Facebook. But with an update launched Friday, users can now pull the embed code for any post to embed it on pages across the Web.
The update, which includes some other minor performance improvements, appears designed to broaden the app's reach while still retaining its in-the-moment, personal storytelling vibe.
"When we launched Vine, we described posts as 'little windows into the people, settings, ideas and objects that make up your life,'" Dom Hofmann, Vine's cofounder and general manager, said in a blog post.
"With today's update, you can display them almost anywhere," he said.
There are two ways to grab the embed code with the update: It can either be pulled from a post's page on vine.co, or by using the latest version of the app that was made available Friday.
In the new version of the app, users can tap the "..." button in the lower-right corner of any post within Vine to either share it on Twitter or Facebook, or access a link directing them to a webpage with the embed code. The webpage will generate a different embed code for the video depending on how large the user wants it to appear, and whether it is displayed in a simple, bare-bones fashion or as a "postcard," like how it would appear on Vine.
The new functionality works for users' own posts as well as others'. Vine acknowledges the possible privacy concerns: The embed code options are only available for posts that have already been shared on networks outside of Vine.
Here, for instance, is the page for a Vine video shot this morning by the IDG News Service at the Game Developers Conference in San Francisco.
The post-anywhere features work similarly to the embed functionality already offered by YouTube. The features also raise some questions over whether they might weaken Vine, or Twitter's, grip on its network of users as they see more videos outside the sites. Vine did not immediately respond to comment on these issues.
Twitter launched Vine in January as a mobile video sharing service allowing users to create and post six-second looped videos. It's super-short, in-the-moment style mimicked the way many people already use the site for 140-character messages.
Friday's update also fixes an issue that caused the camera to freeze when starting a new recording, and resolved a bug that caused the camera to record without touching the screen, Vine said.
Zach Miners covers social networking, search and general technology news for IDG News Service. Follow Zach on Twitter at @zachminers. Zach's e-mail address is zach_miners@idg.com
When new intelligence meets new learning
More from LogicMonitor
Tags social mediamobileinternetFacebooktwittersocial networkingvideomobile applicationsyoutubeentertainmentInternet-based applications and servicesVine
What's next for MSPs and security?


text:
Nervová poškození je druh zranění, při kterém dochází k poškození nervu. Existují tři stupně poškození: neuropraxie, axonotmeze a neurotmésie.

Neuropraxie
Jde o nejlehčí typ poškození, který se obvykle zahojí sám. Nedochází k narušení axonu (samotné nervové vlákno), ale jen k narušení jeho myelinového obalu, podílejícím se na přenášení nervových vzruchů, ale i to stačí na snížení jeho funkce a bolestivost. Hojení trvá několik hodin až 2 týdny, nejčastěji vzniká v důsledku skřípnutí nervu, zahojení kompletní.

Axonotmeze
Dochází k porušení axonu, avšak celkově nerv stále drží pohromadě, nedošlo k jeho úplnému přerušení. Zde jsou už důsledky závažnější a dochází až k ochrnutí svalů, ztrátě citlivosti nebo narušení smyslového vnímání. V tomto případě je stále nerv schopen samoléčby a porušený axon se zregeneruje, to znamená že z konce bližšího k mozku začnou vyrůstat vlákna směrem k utrženému zbytku a následně začne nerv opět dorůstat a nahrazovat poškozenou část a celý nerv se opět uvede do funkce, nervy jsou schopny dorůstat rychlostí až 1 mm/den, ale zajít k lékaři je při neurologických potížích více než vhodné.

Neurotmésie
Kompletní přerušení nervu, kdy oddělená část přestává zcela fungovat. Doprovází to obvykle úplný výpadek funkce určitých částí těla, které daný nerv ovládá, například nejde pohybovat určitým svalem, určitá část kůže znecitliví, může se projevit například neschopní pohnout končetinou. Nerv se v tomto případě stěží vyléčí sám, pokud se přetržené části nedotýkají, proto je nutné jeho chirurgické spojení, jinak dochází k utvoření na konci živé části bouličky zvané neurom a zůstávají problémy s ovládáním svalů, citlivostí kůže a citovým vnímáním.

Reference

Externí odkazy

Neurotraumata
Nervová soustava


Have you ever seen so many partisans running around with their hair on fire as they were yesterday after a short excerpt from the forthcoming book by Donna Brazile, the former interim chair of the Democratic National Committee, was posted on Politico? Oh boy, that was something! So much outrage and fighting!
The reactions have been predictable and totally expected. They are exactly what the publisher wanted in the campaign to promote the book, Hacks: The Inside Story of the Break-ins and Breakdowns that Put Donald Trump in the White House, which will be released on Tuesday. The most salacious parts of books are always what publishers want distributed ahead of a book's release. That's to garner significant media attention and discussion. Hachette, Brazile's publisher, has been very successful in generating a lot of buzz, that's for sure.
Headlines such as, Inside Hillary Clinton's Secret Takeover of the DNC and Former DNC chair torches Clinton in new book, drive the type of media narrative that publishers love, controversy and behind-the-scenes intrigue. This particular publicity campaign is also fueling a fight among prominent Democratic operatives and grassroots activists, which brings even more attention to it.
The problem with pre-release book publicity campaigns, such as this one, is that the message and point of the book can get lost in the gossip and fighting about the excerpts, and the stories and opinion pieces they generate. Many people will form opinions and make incorrect assumptions about the book, without reading it in its entirety. I'm sure that Ms. Brazile has an important message about the systemic problems in her party, and the national security risks from foreign governments' interfering in our elections, and I hope that doesn't get lost in the banter about controversial specific actions by Hillary Clinton's campaign, or anyone else in 2016.
I have some experience with that. My book, No Hope: Why I Left the GOP (and You Should Too), published two years ago, carried a message about how the Republican Party is an untenable coalition, and also about how the two-party system is broken and leaves out the majority of Americans. I used my personal experiences as an openly gay Republican activist, working on issues affecting LGBT Americans, as many of my examples in making my points. Of course, the published excerpts and news stories about my book focused on the behind-the-scenes stories and what I said about specific people. Too many potential readers got the impression that my book was just about how anti-gay the GOP is, something everyone in America already knows. So, it didn't sell very well.
Interestingly, when I run into people who have read my book, I always get praise for my take on the state of the political system. People agree with my assessment and tell me they hope everyone reads the book.
To be honest, one of my take-aways from the Brazile excerpt, is that I was absolutely correct on a major point I wrote about in my book. I wrote that both of the two-major parties are willing to do anything, including compromising their integrity, to gain and maintain power. That's certainly appears to be what happened when the financially desperate DNC turned to candidate Hillary Clinton for help in raising money in order to stay afloat.
That's all to say, at the end of the day, I hope that everyone takes the time to read Brazile's whole book, rather than making assumptions on its content based on a few pages of juicy gossip that the publisher released to boost pre-sales. I know that I am interested in all of what she has to say, and will be open to learning more about our political process, based on her experiences in 2016.
Originally published at jimmylasalvia.com on November 3, 2017.


There are so many traveling guides on the Internet and this means that good advice is hard to find, however this article will provide you with all the best tips and ideas, so you are in the right place to find information on how to get that amazing vacation you have been dreaming of.
If you are going to be traveling with children, it is a good idea to pack a bag for each one, filled with things that you know will amuse and entertain that particular one, and also feed them. A book or two, video games, and some snacks. This will save you from a lot of headaches and keep them happy and occupied for the duration of your trip, instead of cranky and bored.
If you want to get the most out of a travel budget that's limited, try package tours. Find out all the activities that you would like to do before hand and scout for a package deal that includes as many of them as possible. This will save you a lot of money compared to deciding what you would like to try on the spot and paying individually for each service.
The most stressful part of a trip, is usually the airport, everyone is tense, from the travelers to the airline employees. A seasoned traveler would already know and expect this so they would prepare for it, keeping their cool and remembering that everyone is just trying to reach their destination without any hassle.
It is not uncommon to want to take pictures of where you visit, the people, the places, the culture, but it is always best to ask permission first before you take pictures. A lot of people don't like it when their picture is taken randomly and without consent, so it is simply best to take pictures only after permission. Not doing this could even lead to violence.
If you are interested in overseas jobs you should look for administrations which specialize in these services, like for example is you plan to visit the Philippines and you are looking for job hiring abroad you would want to find a POEA agency. A POEA accredited agency is one backed by the Philippine Overseas Employment Administration. To get POEA hiring you could search online for a POEA job opening to get POEA jobs abroad.
Try to walk as much as you can to avoid your ankle swelling in your ankles and soreness in your joints. Walk around on the plane as much as you can, use the bathroom, walk up and down the aisle, move around, and this will help your body stay in good shape.
When in a foreign country, a new place your body is unfamiliar with, do not drink their water. The water might be clean and drinkable, but different countries treat their water in different ways and your body will not be used to it. it is a lot better to drink bottled water all the way, so you don't end up sick.
Take toilet paper with you on your travels. A lot of the time toilet paper is a luxury during travels, and you will find it being scarce and sometimes, even stranded without any, so simply take along some rolls of tissue paper before you get on your way.
Documents are very important, so make absolutely certain that you know the kind of visa you will need to be granted access to any country you want to visit. A visa can take a lot of time before it is ready, so it is a great idea to start your processing early. If you have the wrong visa, you could be unable to visit some countries.
Now that you have gotten the travel advice you needed you can apply them as you finally take that trip in full confidence that it will be just fine.