======
From eb29a25dd6dddc511388bf883c9b95843ecdb823 Mon Sep 17 00:00:00 2001
From: Adrian Johnson <ajohnson@redneon.com>
Date: Tue, 16 Nov 2010 13:18:39 +0000
Subject: win32: Use a font_face hash table to provide unique font faces
Similar to the freetype and toy font backends, use a hash table
to map logfont,hfont to font faces.
This fixes the multiple embedding of the same font in PDF.
https://bugs.freedesktop.org/show_bug.cgi?id=24849
======
From 6e3e329170ab4b96bc0d587c8071e869e228e758 Mon Sep 17 00:00:00 2001
From: Adrian Johnson <ajohnson@redneon.com>
Date: Thu, 18 Nov 2010 12:37:45 +0000
Subject: win32: fix font_face hashing
some bugs were discovered while testing with firefox
======
From 101fab7cd8a90f7cf3d8113c792b3f8c2a9afb7d Mon Sep 17 00:00:00 2001
From: Andrea Canciani <ranma42@gmail.com>
Date: Wed, 15 Jun 2011 09:37:36 +0000
Subject: win32-font: Improve static data reset function
The hashtable is guaranteed to only contain font faces which are
currently referenced, hence there is no need to remove any font face
when it is reset (just like for toy-font).
This makes the function simpler and fixes the assertion
Assertion failed: predicate != NULL, file cairo-hash.c, line 373
hit by multiple tests (the first one being "clear").
See https://bugs.freedesktop.org/show_bug.cgi?id=38049
======
--HG--
extra : rebase_source : 73172c901f80e2f6e9f52035e1d6eab2a220642f
The new version of the code is more obviously correct. Hopefully
the compiler is smart enough to turn it into something fast.
--HG--
extra : rebase_source : bdf2f00c5eae5d5a1bf6dff223b1b05f561384ab
Cairo is a 3rd party project and we decided in bug that silencing the
warnings was easier than patching.
--HG--
extra : rebase_source : aa7a22b208e62d0d84d1b4a6e5c58d366d957bb9
This does a 2x2 ordered dither in the same way that Skia does.
One of the things I'm currently unhappy with is that it duplicates
the gradient walker code for 16 bits. We could turn it into a large
macro that does the appropriate things for 16 bit and 32 bit
versions, but that's not particularly appealing.
This does a 2x2 ordered dither in the same way that Skia does.
One of the things I'm currently unhappy with is that it duplicates
the gradient walker code for 16 bits. We could turn it into a large
macro that does the appropriate things for 16 bit and 32 bit
versions, but that's not particularly appealing.
--HG--
extra : rebase_source : ef89cd53d68166db825bb993e1262db342ba9b5d
Skia uses a value of 0.5, however using such a high value causes some reftest failures.
Switch to 0.3 because we can do that without changing the reftests too much. We
can still use a higher value if we need to later. This should give us sqrt(3)
reduction in the number of segments.
--HG--
extra : rebase_source : 39f1892a61f7e242460deb1bc21adb30778147e3
This takes a trick from skia to go faster. For now, it's only
used on non-NEON devices.
--HG--
extra : rebase_source : c2ddce91cc8cf71ee609420107b0922d1166db43
This will allows us to scale and repeat in a single pass instead
of doing it in two.
--HG--
extra : rebase_source : 8f40aec620494d9c584a3c58cd70ac39723041a4
This takes the bilinear interpolation code from Skia. It
uses 4 bits of precision instead of 8. This lets it interpolate
two components at a time because the results fit in 16 bits.
The lower precision code is only used in the fallback code
and not in any of the specialized code for NEON. This means
pixman gives different results depending on the cpu which isn't
great. However, this was easiest and the NEON code doesn't
gain as much from using lower precision.
Skia actually uses even lower interpolation when working with
565 but that's harder to plug in right now, and this gives
a reasonable improvement.
It seems like we sometimes end up using EXTEND_NONE unintentionally, this is
likely caused by different rounding between cairo and pixman. Pixman already
does a similar reduction to EXTEND_NONE so there's not point in duplicating it
here.
--HG--
extra : rebase_source : 5649a2583a8a01084567bfb06cb3c788437210f5
