The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
Now that we have moz.build, we can be guaranteed that any flags we add
in moz.build will be added after everything else has been setup. So any
uses of MODULE_OPTIMIZE_FLAGS can be moved to moz.build's
CFLAGS/CXXFLAGS without any unusual repercussions. We do have to verify
that MOZ_OPTIMIZE is in effect, though.
qcms and libav use __attribute__((force_align_arg_pointer))
unconditionally; the libav use case suggests that the attribute has been
around since GCC 4.2. We're well past that point with GCC, and clang
supports it also. So we can simply assume the compiler has it in the
appropriate places.
It is, however, x86 only (x86-64 appropriately aligns the stack at all
times), so we need to adjust the libpixman build code appropriately.
The fix for _cairo_bentley_ottmann_tessellate_boxes is from cairo upstream
commit 11b6c49c103d53526e9805c8906fde5dbb2eb884.
--HG--
extra : rebase_source : f9a52a5c6d20e560946abc4fb61bfd4a71fafb6a
Cherry-pick cairo upstream rev 70cc8f250b5669e757b4f044571ba0f71e3dea9e and add CoreText include for iOS
--HG--
extra : commitid : JgGU6cuhap3
extra : rebase_source : c3d45f452d5a7e04adfc0468cddb5e722778c9fb
This patch is derived from upstream commit
5d150ee111c222f09e78f4f88540964476327844, without the build/ parts,
which we don't use. In lieu of the build/ parts in the original patch,
we set the appropriate configuration bit manually in moz.build.
Cairo has a number of nifty features predicated on support for atomic
operations on integer types. Normally, such support would be determined
by cairo's configure script. But since we don't run cairo's configure
script, we need to manually define HAVE_INTEL_ATOMIC_PRIMITIVES during
cairo's build. That macro enables codepaths that depend on certain
SIZEOF_* variables being defined by autoconf, so we also need to add the
necessary code in moz.build to set those.
--HG--
extra : rebase_source : 2f00c4e48145b9f72839c57a619058a7bdec8efd
Cairo has a number of nifty features predicated on support for atomic
operations on integer types. Normally, such support would be determined
by cairo's configure script. But since we don't run cairo's configure
script, we need to manually define HAVE_INTEL_ATOMIC_PRIMITIVES during
cairo's build. That macro enables codepaths that depend on certain
SIZEOF_* variables being defined by autoconf, so we also need to add the
necessary code in moz.build to set those.
This is required to build with clang-cl because it wraps the msvc
intrinsics in intrin.h
--HG--
extra : rebase_source : db1945bfceec5e9657f7bc93de0256b20bab70a1
This isn't technically correct because these functions will never call
functions that throw exceptions, however it lets the profiler unwind them.
The unwinding will also probably be wrong during prologue/epilogue. The right
solution is probably to use cfi.
* * *
[ft] Fix resizing of bitmap fonts
From b94a519aad3d5b50aa6de47ee16ee6a099de9791 Mon Sep 17 00:00:00 2001
Say, you were asking cairo for a font at 200px. For bitmap-only fonts,
cairo was finding the closes strike size and using it. If the strike
was at 20px, well, that's what you were getting. We now scale that 20px
strike by a factor of 10 to get the correct size rendering.
Note that by itself this patch doesn't change much on the Linux desktop.
The reason is that the size you are interested in (eg. 200px) is lost by
fontconfig. When you request a font at 200px, fontconfig returns a font
pattern that says 20px, and so the next layers thing you want a font at
20px. To address that, one also needs a piece of fontconfig config that
puts the 200 back into the pixelsize. Something like this:
<match target="font">
<test name="scalable" mode="eq">
<bool>false</bool>
</test>
<edit name="pixelsize" mode="assign">
<times>
<name>size</name>
<name>dpi</name>
<double>0.0138888888888</double> <!--1/72.-->
</times>
</edit>
</match>
I'm going to try to upstream this config so it will be enabled by
default. The config can be a bit smarter. For example, if
metricshinting is enabled and the size difference is small, we may as
well not scale.
The nice thing about this is that the configuration of whether and when
to scale bitmaps will be done in fontconfig, not cairo / Qt / ... code.
---
* * *
[FT] Prefer downscaling bitmap glyphs to upscaling
From a8f1b456db744e33a10b2301df03528787e5b1ca Mon Sep 17 00:00:00 2001
Say, you have bitmap strikes for sizes 50ppem and 100ppem.
To render at 60ppem, it's much better to downscale the 100ppem
bitmap than upscale 50ppem one. Prefer downscaling.
---
* * *
[ft] I meant fabs(), not abs()
From 13bd8d09b44e50649f6fc4d58d036bc32c1d5c5b Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix memory bug in copying bitmaps
From a0f556f37fb7016aa304b7cf0e811c0d38f0b969 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix wrong assumptions
From e738079302a968b7b1fb9101cd4d92a8887bedce Mon Sep 17 00:00:00 2001
If subpixel rendering is enabled, but FT returns a 8bit gray bitmap
(perhaps because the font has 8bit embedded bitmaps) we were hitting
the assertions because the assumptions made were wrong. Fix up.
---
* * *
Towards support loading color glyphs from FreeType
From 2cc353c3dbe01b4d8f65d6de800f2b1d6004a1c2 Mon Sep 17 00:00:00 2001
See comments.
---
* * *
Support 2bit and 4bit embedded bitmaps
From 9444ef09ccde2735258cc1bd2f1912119a32dd88 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix math
From 7d26341072b13a78d4b3fe58779057ac020be487 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Add missing include
From 0554d76402321b25cc952180e4d19436a9038d1a Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix alignment
From 34a747e7bdeba1cfe17318f80fbe6720d47bc023 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Ensure alignment of bitmaps received from FreeType
From 46d9db96d460fea72f0420102e8a90c6a7231f79 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix resizing of bitmap fonts
From b94a519aad3d5b50aa6de47ee16ee6a099de9791 Mon Sep 17 00:00:00 2001
Say, you were asking cairo for a font at 200px. For bitmap-only fonts,
cairo was finding the closes strike size and using it. If the strike
was at 20px, well, that's what you were getting. We now scale that 20px
strike by a factor of 10 to get the correct size rendering.
Note that by itself this patch doesn't change much on the Linux desktop.
The reason is that the size you are interested in (eg. 200px) is lost by
fontconfig. When you request a font at 200px, fontconfig returns a font
pattern that says 20px, and so the next layers thing you want a font at
20px. To address that, one also needs a piece of fontconfig config that
puts the 200 back into the pixelsize. Something like this:
<match target="font">
<test name="scalable" mode="eq">
<bool>false</bool>
</test>
<edit name="pixelsize" mode="assign">
<times>
<name>size</name>
<name>dpi</name>
<double>0.0138888888888</double> <!--1/72.-->
</times>
</edit>
</match>
I'm going to try to upstream this config so it will be enabled by
default. The config can be a bit smarter. For example, if
metricshinting is enabled and the size difference is small, we may as
well not scale.
The nice thing about this is that the configuration of whether and when
to scale bitmaps will be done in fontconfig, not cairo / Qt / ... code.
---
* * *
[FT] Prefer downscaling bitmap glyphs to upscaling
From a8f1b456db744e33a10b2301df03528787e5b1ca Mon Sep 17 00:00:00 2001
Say, you have bitmap strikes for sizes 50ppem and 100ppem.
To render at 60ppem, it's much better to downscale the 100ppem
bitmap than upscale 50ppem one. Prefer downscaling.
---
* * *
[ft] I meant fabs(), not abs()
From 13bd8d09b44e50649f6fc4d58d036bc32c1d5c5b Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix memory bug in copying bitmaps
From a0f556f37fb7016aa304b7cf0e811c0d38f0b969 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix wrong assumptions
From e738079302a968b7b1fb9101cd4d92a8887bedce Mon Sep 17 00:00:00 2001
If subpixel rendering is enabled, but FT returns a 8bit gray bitmap
(perhaps because the font has 8bit embedded bitmaps) we were hitting
the assertions because the assumptions made were wrong. Fix up.
---
* * *
Towards support loading color glyphs from FreeType
From 2cc353c3dbe01b4d8f65d6de800f2b1d6004a1c2 Mon Sep 17 00:00:00 2001
See comments.
---
* * *
Support 2bit and 4bit embedded bitmaps
From 9444ef09ccde2735258cc1bd2f1912119a32dd88 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix math
From 7d26341072b13a78d4b3fe58779057ac020be487 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Add missing include
From 0554d76402321b25cc952180e4d19436a9038d1a Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix alignment
From 34a747e7bdeba1cfe17318f80fbe6720d47bc023 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Ensure alignment of bitmaps received from FreeType
From 46d9db96d460fea72f0420102e8a90c6a7231f79 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix resizing of bitmap fonts
From b94a519aad3d5b50aa6de47ee16ee6a099de9791 Mon Sep 17 00:00:00 2001
Say, you were asking cairo for a font at 200px. For bitmap-only fonts,
cairo was finding the closes strike size and using it. If the strike
was at 20px, well, that's what you were getting. We now scale that 20px
strike by a factor of 10 to get the correct size rendering.
Note that by itself this patch doesn't change much on the Linux desktop.
The reason is that the size you are interested in (eg. 200px) is lost by
fontconfig. When you request a font at 200px, fontconfig returns a font
pattern that says 20px, and so the next layers thing you want a font at
20px. To address that, one also needs a piece of fontconfig config that
puts the 200 back into the pixelsize. Something like this:
<match target="font">
<test name="scalable" mode="eq">
<bool>false</bool>
</test>
<edit name="pixelsize" mode="assign">
<times>
<name>size</name>
<name>dpi</name>
<double>0.0138888888888</double> <!--1/72.-->
</times>
</edit>
</match>
I'm going to try to upstream this config so it will be enabled by
default. The config can be a bit smarter. For example, if
metricshinting is enabled and the size difference is small, we may as
well not scale.
The nice thing about this is that the configuration of whether and when
to scale bitmaps will be done in fontconfig, not cairo / Qt / ... code.
---
* * *
[FT] Prefer downscaling bitmap glyphs to upscaling
From a8f1b456db744e33a10b2301df03528787e5b1ca Mon Sep 17 00:00:00 2001
Say, you have bitmap strikes for sizes 50ppem and 100ppem.
To render at 60ppem, it's much better to downscale the 100ppem
bitmap than upscale 50ppem one. Prefer downscaling.
---
* * *
[ft] I meant fabs(), not abs()
From 13bd8d09b44e50649f6fc4d58d036bc32c1d5c5b Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix memory bug in copying bitmaps
From a0f556f37fb7016aa304b7cf0e811c0d38f0b969 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix wrong assumptions
From e738079302a968b7b1fb9101cd4d92a8887bedce Mon Sep 17 00:00:00 2001
If subpixel rendering is enabled, but FT returns a 8bit gray bitmap
(perhaps because the font has 8bit embedded bitmaps) we were hitting
the assertions because the assumptions made were wrong. Fix up.
---
* * *
Towards support loading color glyphs from FreeType
From 2cc353c3dbe01b4d8f65d6de800f2b1d6004a1c2 Mon Sep 17 00:00:00 2001
See comments.
---
* * *
Support 2bit and 4bit embedded bitmaps
From 9444ef09ccde2735258cc1bd2f1912119a32dd88 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix math
From 7d26341072b13a78d4b3fe58779057ac020be487 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Add missing include
From 0554d76402321b25cc952180e4d19436a9038d1a Mon Sep 17 00:00:00 2001
---
* * *
[ft] Fix alignment
From 34a747e7bdeba1cfe17318f80fbe6720d47bc023 Mon Sep 17 00:00:00 2001
---
* * *
[ft] Ensure alignment of bitmaps received from FreeType
From 46d9db96d460fea72f0420102e8a90c6a7231f79 Mon Sep 17 00:00:00 2001
---
Nicholas Nethercote
Nathan Froyd
Lee Salzman
Bas Schouten
Ehsan Akhgari
Tom Klein
Ryan VanderMeulen
Ted Mielczarek
David Major
Jonathan Kew
Joel Maher
Jacek Caban
Markus Stange
Matt Woodrow
Gian-Carlo Pascutto
Nicolas Silva
Jonathan Kew
Jeff Muizelaar
Chris Peterson
Phil Ringnalda