1. 01 8月, 2015 2 次提交
  2. 15 7月, 2015 2 次提交
    • S
      update stb_truetype version · 93fb3720
      Sean Barrett 提交于
      93fb3720
    • S
      stb_truetype version 1.06 · 20b04f4a
      Sean Barrett 提交于
      - switch from qsort() to built-in quicksort (about 2x as fast a sort, ~10% faster overall)
      - use pool allocator for active-edge allocations (~10% faster overall)
      - use new rasterizer (about 30% faster, ~10% faster overall)
      20b04f4a
  3. 11 6月, 2015 1 次提交
  4. 10 6月, 2015 1 次提交
  5. 29 5月, 2015 1 次提交
  6. 19 4月, 2015 7 次提交
    • S
      update version numbers & docs · 947bdcd0
      Sean Barrett 提交于
      947bdcd0
    • S
      8f9c8b68
    • S
      update version numbers · b4b196af
      Sean Barrett 提交于
      b4b196af
    • S
      bump stb_image to version 2.05, tweak docs · ac5e25ae
      Sean Barrett 提交于
      ac5e25ae
    • F
      stb_image: Progressive AC decoding - fix ZRL code. · f224bc2c
      Fabian Giesen 提交于
      The original AC decoding logic handled ZRL (runs of 16 zeros)
      incorrectly.
      
      The problem is that the original flow set r=16 and skipped the
      final coeff write when s=0. This is not actually correct. The
      problem is the intervening "refinement" bits.
      
      With the original logic, even once we decrement r to 0, we keep
      reading more refinement bits for subsequent coefficients until
      we find the next currently-unsent AC in the current scan. That is,
      it works as if it was trying to place 17 new AC values, and only
      bails at the last minute from actually setting that 17th value.
      
      This is wrong. Once we've found the 16th previously-unsent AC, we
      need to stop reading refinement bits, otherwise we get out of sync
      with the bit stream (which expects us to read a huffman code next).
      
      The easiest fix is to just do what the JPEG standard implicitly
      assumes anyway: treat ZRL as a run of 15 zeros followed by an
      explicit magnitude-zero AC coeff. (That is, leave s=0 and actually
      write s). So this is what this fix does.
      f224bc2c
    • N
      fix signed/unsignted compare warning · 1894bede
      Nicolas Guillemot 提交于
      1894bede
    • N
      don't redefine __forceinline with mingw · fda33560
      Nicolas Guillemot 提交于
      mingw redefines __forceinline (though I don't think this applies to all
      versions of mingw.) Therefore, don't redefine it if mingw has already
      defined it.
      fda33560
  7. 16 4月, 2015 1 次提交
  8. 15 4月, 2015 16 次提交
  9. 14 4月, 2015 9 次提交