Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSync changes from mozilla-central #3809
Merged
Conversation
Differential Revision: https://phabricator.services.mozilla.com/D55113 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/eade7e3b3c6fc9e4150fede8b174cd3732bbfeed
Differential Revision: https://phabricator.services.mozilla.com/D55203 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/1128e943e324d5c6677c47012e66665d07ea1be2
… bustages CLOSED TREE [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/1bc99f34e93fce32097193ffc149ed5de0c1774e
|
@bors-servo r+ |
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 2, 2019
Sync changes from mozilla-central
|
|
added 3 commits
Dec 3, 2019
…no-op. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D54864 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/86427d3d06009b523b5e34c5994e468571a41fcc
Differential Revision: https://phabricator.services.mozilla.com/D54865 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/4351a57052fa1b7bdbd6a8899dd900bb3325a07d
…=nical * The existing code to detect if an image is dirty fails in some cases. For external images, they were not being added to the list of dirty images when update was called. Further, since the dirty image keys hash set was cleared each frame, it was possible for an image to become dirty, but this detection to be missed if it is not queried until a subsequent frame (due to it being off-screen. Instead, each image template has a generation identifier that is incremented whenever an image template is updated. The picture caching code stores the generation of the image key when it was rasterized, and compares that to the current image key generation when comparing dependencies. This fixes both cases above. * Remove the is_cacheable logic that was previously used to invalidate picture cache tiles for external images. This would result in picture cache images that intersect with videos being invalidated every frame unconditionally. However, this code path is no longer required, due to the change above. By relying on the true image dirty check, we can skip invalidating tiles affected by video if the video frame has not advanced (e.g. it is paused, or advancing at a lower frame rate than we are currently compositing at). Differential Revision: https://phabricator.services.mozilla.com/D55061 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/93ccc760c4dd69f63d6ac171ace357b0dd31412a
|
@bors-servo r+ |
|
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 3, 2019
Sync changes from mozilla-central
…stage on central CLOSED TREE a=backout [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/7205934173a46289d53d1cc0091e8bd22541f967
|
@bors-servo r+ |
|
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 3, 2019
Sync changes from mozilla-central
…entral CLOSED TREE a=backout Backed out changeset 4351a57052fa (bug 1599656) Backed out changeset 86427d3d0600 (bug 1599656) [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/8eeadab197dd0e69d69b6c1677dc3d812bb0e823
|
@bors-servo r+ |
|
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 3, 2019
Sync changes from mozilla-central
added 2 commits
Dec 3, 2019
…no-op. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D54864 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/88be4abe8a0d491604e567d936b20e1d12eba5e8
Differential Revision: https://phabricator.services.mozilla.com/D54865 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/1f002f7f079d3c9cf4126bf455749a8ba916dc11
|
|
Differential Revision: https://phabricator.services.mozilla.com/D55562 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/fa562908e657400cd86b846e766fcd7f9fa73de8
…ead and get rid of Arc r=kvark Differential Revision: https://phabricator.services.mozilla.com/D55563 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/2979006caf1043e83f13db2143d7ffeb5fa9a577
|
@bors-servo r+ |
|
|
…y. r=mstange Differential Revision: https://phabricator.services.mozilla.com/D56316 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/aa07114fb54ab1f7b819522f45563cb83f6b637e
|
@bors-servo r+ |
|
|
…ical Differential Revision: https://phabricator.services.mozilla.com/D56309 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/bdb6fc50b1976cb7939b729dd7bad4ceb0d040a4
|
@bors-servo r+ |
|
|
…865, 1601924, 1602500 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/f47661feecce9b319848f7d77202cfa67334be8f
Uploading texture data is showing up frequently in profiles on Adreno devices, especially when zooming on a text-heavy page. Specifically, the time is spent in glMapBufferRange and glBufferSubData, most likely when internally allocating the buffer before transferring data in to it. Currently, we are creating a new PBO, by calling glBufferData(), for each individual upload region. This change makes it so that we calculate the required size for all upload regions to a texture, then create single a PBO of the required size. The entire buffer is then mapped only once, and each individual upload chunk is written to it. This can require the driver to allocate a large buffer, sometimes multiple megabytes in size. However, it handles this case much better than allocating tens or even hundreds of smaller buffers. An upload chunk may require more space in a PBO than the original CPU-side buffer, so that the data is aligned correctly for performance or correctness reasons. Therefore it is the caller of Device.upload_texture()'s responsibility to call a new function, Device.required_upload_size(), to calculate the required size beforehand. Differential Revision: https://phabricator.services.mozilla.com/D56382 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/3f9482614123972f6fcd8b6a1d99dc8db8cb6c07
|
@bors-servo r+ |
|
|
|
@bors-servo retry |
|
@bors-servo r+ |
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 10, 2019
Sync changes from mozilla-central
|
|
…tion. r=sotaro Differential Revision: https://phabricator.services.mozilla.com/D56653 [wrupdater] From https://hg.mozilla.org/mozilla-central/rev/62f2e4e975cbeebf1b52b83d2106824db2fa7584
|
@bors-servo r+ |
|
|
|
bors-servo
added a commit
that referenced
this pull request
Dec 11, 2019
Sync changes from mozilla-central
|
|
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
moz-gfx commentedDec 2, 2019
No description provided.