- 17 12月, 2017 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Specificaly, when a range or sorted array has unexpected order, we take that as font data being garbage and bail out. This fixes significant slowdown on a bad version of Chandas font which has a 600KB GPOS with garbage inside. Later on, I like to add a maximum-work counter for collect_glyphs to protect against malicious fonts as well. Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=794896
-
由 Behdad Esfahbod 提交于
Does page lookup as needed.
-
- 16 12月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
The three "XXXXX"'s should be switched to false. Doing that separately for ease of bisecting...
-
- 15 12月, 2017 5 次提交
-
-
由 Behdad Esfahbod 提交于
Not optimized to use sortedness yet. Also start putting in place infra to faster reject bad data. A version of Chandas.ttf found on some Chrome bots has 660kb of GPOS, mostly junk. That is causing 48 million of set->add() calls in collect_glyphs(), which is insane. In the upcoming commits, I'll be speeding that up by optimizing add_sorted_array(), while also reducing work by rejecting out-of-sort arrays quickly and propagate the rejection. Part of https://bugs.chromium.org/p/chromium/issues/detail?id=794896
-
由 Behdad Esfahbod 提交于
Now that pagesize is 8192, this feels better.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Fixes perf regression on some heavy fonts in Chrome's FT+HB interaction. See: https://bugs.chromium.org/p/chromium/issues/detail?id=782220 More work to be done: https://bugs.chromium.org/p/chromium/issues/detail?id=794896
-
由 Behdad Esfahbod 提交于
To be used to optimize adding a whole bunch of (sorted) items at the same time, as in CoverageFormat1.
-
- 03 12月, 2017 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 02 12月, 2017 2 次提交
-
-
由 Behdad Esfahbod 提交于
It's as good as it gets, and seems to be on par with previous set implementation in my benchmark. Would be great if someone can double-check my bitops.
-
由 Behdad Esfahbod 提交于
With new set implementation, this became really costy. Optimize it. There's more to be done, but this shaves off most of the fat. Part of fixing https://bugs.chromium.org/p/chromium/issues/detail?id=782220
-
- 27 10月, 2017 2 次提交
-
-
-
由 Jonathan Kew 提交于
-
- 24 10月, 2017 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Ouch! That's what happens when one plays with increment/decrement operators! Fixes https://github.com/behdad/harfbuzz/issues/578
-
- 23 10月, 2017 3 次提交
-
-
-
-
由 Behdad Esfahbod 提交于
-
- 18 10月, 2017 1 次提交
-
-
由 Behdad Esfahbod 提交于
c:\projects\harfbuzz\src\hb-set-private.hh(151): error C2327: 'hb_set_t::page_t::v': is not a type name, static, or enumerator [C:\projects\harfbuzz\build\harfbuzz.vcxproj]
-
- 16 10月, 2017 8 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Fixes clang "non-const reference cannot bind to vector element" error.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
-
- 15 10月, 2017 4 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 09 8月, 2016 1 次提交
-
-
由 Behdad Esfahbod 提交于
This one: map->mask = (1 << (next_bit + bits_needed)) - (1 << next_bit); before the fix, the shift was done as an int, causing overflow if it ever got to 1 << 31. Sprinkle 'u's around. Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=634805
-
- 25 7月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 09 4月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 26 2月, 2015 1 次提交
-
-
由 Behdad Esfahbod 提交于
I experimented with replacing use of hb_set_digest_t with this new hb_frozen_set_t, hoping to get a huge speedup for busy lookups (like kern lookup in Roboto), but I only got 6% speendup in Roboto and 4% in NotoNastaliqUrduDraft :(.
-
- 15 8月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
In preparation for fixing: https://code.google.com/p/chromium/issues/detail?id=403594
-
- 12 12月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 07 9月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
-