Comments

[FCP++] Replace priority queue with ordered set
In our current design of ImagePaintTiming, we use priority queue to sort the
records. The priority queue provides O(1) operation to find the largest and
last image in records. However, the current usage of priority queue has a design
problem. Priority queue depends on a comparison function to rank the entries.
The comparison function has an assumption that the properties involving
comparison remain constant during the whole life cycle. The current design has
violated this assumption.
In order to fix this issue, we use ordered set to replace priority queue.
Ordered set allows us to iterate on entries by order of size or time, whereas
priority queue doesn't allow iteration unless popping up the head entry.
The new design also has a detached_ids to record the nodes that are detached
from the DOM node. While looking up the largest and last image, the detached
image will be ignored until it's reattached.
Bug: 914933
Change-Id: I3728a375b4d622a8fa62911285e6b162504611e5
Reviewed-on: https://chromium-review.googlesource.com/c/1377726
Commit-Queue: Liquan (Max) Gu <maxlg@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616984}

Comments

[AF] Fix reporting to Autofill.Wallet* diff histograms in Directory
This CL fixes how diff metrics are reported from wallet syncable
service. Unlike the USS implementation, it reported diff metrics on
every startup, leading to inconsistencies in number of samples (and also
to inconsistencies in the distribution of the values).
This CL makes sure we do not report on startup
(in MergeDataAndStartSyncing()) but only in real updates
(ProcessSyncChanges()).
Bug: 908905
Change-Id: I813cc9629febdecc3f10929a73345539e12eb842
Reviewed-on: https://chromium-review.googlesource.com/c/1373451
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org>
Commit-Queue: Jan Krcal <jkrcal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616981}

Comments

Change QpackEncoderStreamSenderTests to use a mock delegate.
Since QpackEncoderStreamSender has been converted to use
QpackInstructionEncoder, it is guaranteed to call Delegate::Write() exactly once
per instruction sent. Document this in the header file. Also, this allows
tests to use a mock delegate, and have one expected call per instruction
encoded, which makes it easier to identify what fragment of the encoded data
belongs to each instruction.
This CL merges internal changes 222418576 and 225631270 by bnc.
Change-Id: Ibbb0d8c1c56711026e3e46eb2ecac503672f36ca
Reviewed-on: https://chromium-review.googlesource.com/c/1378577
Commit-Queue: Bence Béky <bnc@chromium.org>
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616978}

Comments

Revert "Try capturing incorrect re-entrancy into DWriteFontProxy"
This reverts e630455cf22a85822e681f0c84134193aed73433.
The detection mechanism did not detect any crashes of this kind. While
it's still very likely that the crashes are caused by Mojo sync calls
reentrancy issues, the particular theory of this change did not seem to
match what's going on. We should perhaps try to capture the re-entrancy
of font calls at the Mojo level, or move the font calls to a separate
blocking thread to avoid interference with other Mojo calls.
Bug: 561873
Change-Id: If0a1ce3b20fdf1f12afe1440db5b7989659a5e47
Reviewed-on: https://chromium-review.googlesource.com/c/1378141
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616976}

Comments

Roll AFDO from 73.0.3640.0_rc-r1 to 73.0.3641.0_rc-r1
This CL may cause a small binary size increase, roughly proportional
to how long it's been since our last AFDO profile roll. For larger
increases (around or exceeding 100KB), please file a bug against
gbiv@chromium.org. Additional context: https://crbug.com/805539
Please note that, despite rolling to chrome/android, this profile is
used for both Linux and Android.
The AutoRoll server is located here: https://autoroll.skia.org/r/afdo-chromium-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.
TBR=gbiv@chromium.org
Change-Id: I49aaf434c12a553bf5c247a52bc749605cfc8d01
Reviewed-on: https://chromium-review.googlesource.com/c/1379335
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#616970}

Comments

Fix gradient background sizing
This is a hard-to-fix situation. We size generated background images
according to the tile size, which is a snapped rectangle sized according
to the destination values, in general. But then we compute a src rect
for image drawing using the unsnapped values, because that is best for
bitmap images where we want to pull out the most accurate src rect
possible. However, that source rect ends up larger than the tile size
due to rounding without the original offset in the layer (because now
we are working in image space).
The gradient painting code then sees that it has a src rect that is
larger than the tile size and hence the gradient image size. The code
thinks that we want to have some more pixels than the gradient
provides, which is true in some cases, and scales things to get those
extra pixels in the painted output. Hence empty pixels on the screen
when we really want the gradient to be filling the dest rect.
Changing the gradient painting code will break valid use cases. Changing
the tile size breaks things in a different way and doesn't really fix
the problem. So change the src rect computation to use snapped sizes
for generated content in an attempt to get a src that matches the tile
size.
R=fmalita@chromium.org
Bug: 898950
Change-Id: I100575ad4f4fa3004fbc232a72c90b0032ccef4e
Reviewed-on: https://chromium-review.googlesource.com/c/1376814
Commit-Queue: Stephen Chenney <schenney@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616944}

Comments

Remove flattenhtml from Print Preview
With the update to GM2, locations in Print Preview that were using
inlined images have now been updated to iron-icons and .cr-icons, so
flattenhtml can be removed entirely in print_preview_resources.grd, and
replaced with preprocess in print_preview_resources_vulcanized.grd.
This requires modifying tools/grit/grit/node/include.py, to allow the
use of preprocess in <include>s.
Bug: None
Change-Id: If2b099b47ef136ff8487ea1cc812ce8f29d02036
Reviewed-on: https://chromium-review.googlesource.com/c/1377500
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616943}

Comments

Complete the screen capture color space plumbing.
Adds all remaining "plumbing" of color space information, throughout the
CopyOutputRequest execution pipeline and the FrameSinkVideoCapturer
pipeline. This ensures the color space being used to draw the original
RenderPass within the compositor is being specified in the metadata for
all result images.
DevTools: Remove a hack from the color picker tool, now that the color
space information for the screen capture frame is being provided.
browser_tests/content_browsertests changes: Multilple browser tests were
fixed as a result of this change revealing pre-existing bugs in the
tests: the web page layout of the color regions, how pixels were being
selected for analysis, and YUV→RGB color space conversion inaccuracies.
Blink layout tests: Rebased a number of layout test expectations, as the
the layout tests utilize the screen capture pipeline. I examined all of
these changed expectations to confirm near 0% change: Meaning that just
a tiny number of pixels in an image were imperceivably different because
of adding the missing color space info.
Bug: 758057, 8510131, 809835, 863103, 884170, 795132
Change-Id: I11056ddc4f501ee338dc3283397703747a395571
Reviewed-on: https://chromium-review.googlesource.com/c/1372894
Commit-Queue: Yuri Wiitala <miu@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Ria Jiang <riajiang@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616936}

Comments

GuestView: No TextInputManager when unattached
TextInputManager is created lazily the first time GetTextInputManager
is called on WebContents. Given that TextInputManager should only exist
for the outermost WebContents, there is no point in creating it for an
unattach guest WebContents only to clear it after attaching. Also, it
seems incorrect to try to access |text_input_manager_| for an unattached
guest WebContents.
Bug: 609846
Change-Id: I0b60a0a3160909f9d8c0b6a4c099c3f4769af0ff
Reviewed-on: https://chromium-review.googlesource.com/c/1376090
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: Ehsan Karamad <ekaramad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616934}

Comments

Fix a race in headless virtual time & compositor tests
A lack of explicit start time for frame caused real time clock to
be used for frame start, which may cause next frame to be dropped
if its (virtual) timestamp is earlier.
Bug: 909043, 843734
Change-Id: I4a909be2e1e4f69f0834a87ffdb3d402c450adfc
Reviewed-on: https://chromium-review.googlesource.com/c/1379181
Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616925}

Comments

[Audio Focus] Observer should use request state
The AudioFocusObserver should use AudioFocusRequestState
instead of separate parameters for OnFocusGained/Lost. This
was not the case before because AFRS was added after the
observer.
We need this to expose the request id to clients so they
can get a MediaController that will only control a specific
session.
BUG=892771
Change-Id: I4f6e2e60de6dbc82f779ffbfec3d91628208c42d
Reviewed-on: https://chromium-review.googlesource.com/c/1363684
Commit-Queue: Becca Hughes <beccahughes@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Tommy Steimel <steimel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616916}

Comments

viz: Always request presentation timestamp from clients.
Turn on CompositorFrameMetadata.request_presentation_feedback by
default. This would start sending presentation-feedback for every frame
submitted by a client. However, the presentation-feedback is now
included with the begin-frame messages (crrev.com/608235}, so there is
no longer an extra IPC per frame. There is one extra ipc that gets sent:
when the client submits the last frame, and does not want any more
begin-frames, it still receives a begin-frame carrying the
presentation-timestamp for the last submitted frame. But the cost of
this is small.
This now requires that submitted CompositorFrame has a valid token.
A viz::FrameTokenGenerator is introduced to facilitate creating the
tokens from the clients. A DCHECK() is also added in the serializer
to catch clients sending a CompositorFrame without a valid token.
After this stays in tree for a few days, a follow up CL will remove the
CompositorFrameMetadata.requested_presentation_feedback flag, and the
associated code.
TBR=fserb@ for third_party/blink changes.
TBR=Bo for android_webview/ changes.
TBR=oshima@ for ash/ and components/exo changes.
BUG=883592
Change-Id: I70b9b290cab5a31d6cc7597bd737402f9459c10f
Reviewed-on: https://chromium-review.googlesource.com/c/1375641
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616913}

Comments

Remove deprecated CustomFeedback flow for Android.
It was never launched and there are no plans to ramp it up
past the very, very old experiment.
BUG=913677
Change-Id: I66e22b3f16693a98104dcf56e5bb1dc8ac6fd786
Reviewed-on: https://chromium-review.googlesource.com/c/1372360
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Ted Choc <tedchoc@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616911}

Comments

Record metrics for connected gamepads
Update the Gamepad.ConnectedDevice histogram when a device is
connected with a vendor and product ID pair matching a known
USB or Bluetooth gaming peripheral.
If the connected device is not recognized as a known gamepad, the
ID is not recorded. If the data fetcher that enumerated the
device has an independent means of verifying whether a device is
a gamepad, record an enum representing the data fetcher to the
Gamepad.UnknownGamepad histogram.
BUG=786250
Change-Id: I7e7797ee1e99b2076aa331ee9e589d157016993b
Reviewed-on: https://chromium-review.googlesource.com/c/1299543
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616905}

Comments

Enable mojo video decoders by default on Linux desktop if use_vaapi is true
Already the case for ChromeOS, Mac and Win. And run the service
in the GPU process too. Except that here the gn arg use_vaapi
has to be true as well.
Note that this CL does not change the following:
- the gn arg 'use_vaapi' is still false by default on Linux,
see media/gpu/args.gni
- 'accelerated_video_decode' is still black listed on Linux,
see entry 48 in gpu/config/software_rendering_list.json
- it is still not possible to enable hw video decode from
about:flags, see chrome/browser/about_flags.cc
Also note that with this CL the ffmpeg and libvpx video decoders
are still selected thanks to media::DecoderSelector::SelectDecoder
in case vaapi fails to initialize.
Also see https://chromium-review.googlesource.com/c/chromium/src/+/1225275/
which was very similar but for ChromeOS.
Tested on Linux desktop with gn args:
- use_vaapi = true (default is false)
./out/release/chrome --ignore-gpu-blacklist --use-gl=desktop url_to_vp9_video
./out/release/chrome --ignore-gpu-blacklist --use-gl=egl url_to_vp9_video
-> MojoVideoDecoder was in use and VaapiVideoDecodeAccelerator runing in the
GPU process, through MojoVideoDecoderService
Bug: 522298
Change-Id: Ia19f9f3edc0af488a477a16001b7de4f4818b3b2
Reviewed-on: https://chromium-review.googlesource.com/c/1370717
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Julien Isorce <julien.isorce@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616901}

Comments

chromeos: gets a bunch of MultiUserWindowManager related tests passing
MultiUserWindowManagerClientImpl, when running in single-process mash mode,
expects a MusClient. So, tests that end up using AshTestBase/Helper *and*
calling into MultiUserWindowManager need to ensure there is a MusClient.
This also adds some calls to FlushBindings() at key points to ensure ash has
completed processing. This is necessary as ash may change visibility of
registered windows.
BUG=910241
TEST=covered by tests
Change-Id: Ie7bcba3772284d0c2b53ab26b0e3ad50c3153928
Reviewed-on: https://chromium-review.googlesource.com/c/1378411
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616897}