Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Rendering glyphs at many different rotations was causing the D2D glyph
cache to grow very large. Calling EndDraw/BeginDraw will prune the
cache, but is costly, so only do it for every 1000 glyphs.
MozReview-Commit-ID: HUFpxDvYAzQ
--HG--
extra : rebase_source : de283c5e687da07e5417e0d221d7f45b992080d5
We can't use memcmp to compare PODs, largely because of undefined
padding. The rest of the Pod* functions are fine though, since we're
replicating or zeroing PODs.
MozReview-Commit-ID: LSspAi8qCWw
When masking as a secondary effect to RENDER_TARGET, mFBOTextureTarget
will have a target of GL_TEXTURE_2D, leading us to not use sampler2DRect
and friends for the mask. This fixes that, and also assures our coord
adjustments are based on the mask texture's dimensions.
MozReview-Commit-ID: JSDfDJuLNSa
--HG--
extra : rebase_source : 77010ae331f4d004e9b716e6063334d98529bf5f
Now that the shader problems are fixed it's a simple switch.
MozReview-Commit-ID: 6MJlEVITwii
--HG--
extra : rebase_source : cb33bd45196eca26476c52c2c50e51f03f6129f8
I'm not sure if there was a reason for not fully generalizing the
sampler2DRect and texture2DRect stuff throughout the shader
generalization file. It seemed the simplest thing was to fully
replace it - even if in some cases it doesn't make sense it's
more consistent, and it definitely fixes the trouble we were having
with switching to GL_TEXTURE_RECTANGLE_ARB for client storage.
MozReview-Commit-ID: 7243OjQdakN
--HG--
extra : rebase_source : 756741bbff4c56edec64cc6dd367328974b83b35
When masking as a secondary effect to RENDER_TARGET, mFBOTextureTarget
will have a target of GL_TEXTURE_2D, leading us to not use sampler2DRect
and friends for the mask. This fixes that, and also assures our coord
adjustments are based on the mask texture's dimensions.
MozReview-Commit-ID: JSDfDJuLNSa
--HG--
extra : rebase_source : c779b18789196c9352a862a17f4a1e8d799805ec
Now that the shader problems are fixed it's a simple switch.
MozReview-Commit-ID: 6MJlEVITwii
--HG--
extra : rebase_source : 7c91165633d5bc4fb07135781774998b0e1f1cf0
I'm not sure if there was a reason for not fully generalizing the
sampler2DRect and texture2DRect stuff throughout the shader
generalization file. It seemed the simplest thing was to fully
replace it - even if in some cases it doesn't make sense it's
more consistent, and it definitely fixes the trouble we were having
with switching to GL_TEXTURE_RECTANGLE_ARB for client storage.
MozReview-Commit-ID: 7243OjQdakN
--HG--
extra : rebase_source : d1b9f51f45d0cb875c82f3de5b2ea917e0385077
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 3e497f254ce91e4a8e539d475f90690831bcbe07
This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
system-info is a stub on Tier3 platforms while physical vs. logical
difference only matters for hyper-threading. As hyper-threading
is usually available on CPUs with more than 2 physical cores this
change has no impact there as the default is clamped to [1, 4].
However, on Intel i3-* CPUs with 2 physical and 4 logical cores this
bumps the default from 1 to 3.
MozReview-Commit-ID: 1Yh8rJL2JcN
--HG--
extra : rebase_source : 77613cbb99c14f19217592080bfd51ea2194422b
This restricts the active-item-detection code to wrap lists and
perspective items because other wrapper items are not supported yet.
MozReview-Commit-ID: JuirkAId7Kk
--HG--
extra : rebase_source : 971de2c56d183090bb9a8701af62ada493e39b77