1. 03 Feb, 2015 14 commits
  2. 02 Feb, 2015 18 commits
    • Ravi Mistry's avatar
      f4a61f8b
    • stephana's avatar
      Revert of make getContentKey() available in GrGpuResource public interface... · 9b440260
      stephana authored
      Revert of make getContentKey() available in GrGpuResource public interface (patchset #2 id:20001 of https://codereview.chromium.org/886313005/)
      
      Reason for revert:
      This causes in one case the linker and in the other the compiler to segfault. On
      
      Test-Ubuntu12-ShuttleA-GTX660-x86_64-Debug/Release
      
      Original issue's description:
      > make getContentKey() available in GrGpuResource public interface
      >
      > TBR=robertphillips@google.com
      >
      > Committed: https://skia.googlesource.com/skia/+/85ed2db092e75db41b711b9116a8d5b465fc2b0c
      
      TBR=robertphillips@google.com,bsalomon@google.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/864343005
      9b440260
    • bsalomon's avatar
      make getContentKey() available in GrGpuResource public interface · 85ed2db0
      bsalomon authored
      TBR=robertphillips@google.com
      
      Review URL: https://codereview.chromium.org/886313005
      85ed2db0
    • mtklein's avatar
      DM: wire up --leaks / -l again · e67164d9
      mtklein authored
      No public API changes.
      TBR=reed@google.com
      
      BUG=skia:
      
      Review URL: https://codereview.chromium.org/893043002
      e67164d9
    • bsalomon's avatar
    • caryclark's avatar
      move HelloWorld to be a peer of SampleApp · 52edc4d0
      caryclark authored
      This is working towards making a simple example part of the buildbot compile step and removing SkExamples from the experimental directory.
      
      This works on Mac, Windows, and Linux but isn't complete for Android, ChromeOS and iOS.
      
      Review URL: https://codereview.chromium.org/886413004
      52edc4d0
    • reed's avatar
      76113a9b
    • mtklein's avatar
      Atomics overhaul. · a669bc7a
      mtklein authored
      This merges and refactors SkAtomics.h and SkBarriers.h into SkAtomics.h and
      some ports/ implementations. The major new feature is that we can express
      memory orders explicitly rather than only through comments.
      
      The porting layer is reduced to four template functions:
        - sk_atomic_load
        - sk_atomic_store
        - sk_atomic_fetch_add
        - sk_atomic_compare_exchange
      From those four we can reconstruct all our previous sk_atomic_foo.
      
      There are three ports:
        - SkAtomics_std:    uses C++11 <atomic>,             used with MSVC
        - SkAtomics_atomic: uses newer GCC/Clang intrinsics, used on not-MSVC where possible
        - SkAtomics_sync:   uses older GCC/Clang intrinsics, used where SkAtomics_atomic not supported
      
      No public API changes.
      TBR=reed@google.com
      
      BUG=skia:
      
      Review URL: https://codereview.chromium.org/896553002
      a669bc7a
    • rmistry's avatar
      Add missing SK_OVERRIDE · 465206af
      rmistry authored
      Tested by running on clang head + ubuntu 14.04:
      GYP_DEFINES=”skia_gpu=0 skia_warnings_as_errors=1" tools/xsan_build thread dm BUILDTYPE=Release
      out/Release/dm -v
      
      BUG=skia:3386
      
      Review URL: https://codereview.chromium.org/894833002
      465206af
    • mtklein's avatar
      add missing SK_OVERRIDE · 004a166a
      mtklein authored
      BUG=skia:
      
      Review URL: https://codereview.chromium.org/894153002
      004a166a
    • bungeman's avatar
      Don't read unecessary font files on Android. · efbad371
      bungeman authored
      With a new style fonts.xml (version >= 21) fallback fonts are specified
      as font families without a name. The current code reads these, but then
      also reads in the old fallback and vendor xml files. With this change,
      when a new style xml file is encoutered, no further files will be read.
      This both lowers memory use and speeds font lookup. Locally, this
      change reduces the number of font families loaded on my 'L' device from
      148 to 80. All of the families removed are duplicates.
      
      Review URL: https://codereview.chromium.org/888923003
      efbad371
    • stephana's avatar
      Revert of Revert of SSE4 opaque blend using intrinsics instead of assembly.... · 4bf1ce27
      stephana authored
      Revert of Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset #1 id:1 of https://codereview.chromium.org/873553003/)
      
      Reason for revert:
      Reverted the wrong CL.
      
      Original issue's description:
      > Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset #16 id:300001 of https://codereview.chromium.org/874863002/)
      >
      > Reason for revert:
      > This causes a bug on the 'hittestpath' GM on MacMini 4,1
      >
      > See:
      >
      > https://gold.skia.org/#/triage/hittestpath?head=0
      >
      > for details.
      >
      > Original issue's description:
      > > SSE4 opaque blend using intrinsics instead of assembly.
      > >
      > > Since we had such a hard time with the assembly versions of this blit (to the
      > > point that we have them completely disabled everywhere), I thought I'd take
      > > a shot at writing a version of the blit using intrinsics.
      > >
      > > The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*)
      > > to skip the blend when the 16 src pixels we consider each loop are all opaque
      > > or all transparent.  _mm_shuffle_epi8 from SSSE3 also lends a hand to extract
      > > all those alphas.
      > >
      > > It's worth looking to see if we can backport this type of logic to SSE2 using
      > > _mm_movemask_epi8, or up to 32 pixels at a time using AVX.
      > >
      > > My local performance testing doesn't show this to be an unambiguous win
      > > (there are probably microbenchmarks and SKPs where we'd be better off just
      > > powering through the blend rather than looking at alphas), but the potential
      > > does seem tantalizing enough to let skiaperf vet it on the bots.  (< 1.0x is a win.)
      > >
      > > DM says it draws pixel perfect compare to the old code.
      > >
      > > Microbenchmarks:
      > >                bitmap_RGBA_8888_A_source_stripes_two	  14us -> 14.4us	1.03x
      > >              bitmap_RGBA_8888_A_source_stripes_three	14.3us -> 14.5us	1.01x
      > >                        bitmap_RGBA_8888_scale_bilerp	61.9us -> 62.2us	1.01x
      > > bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp	 102us ->  101us	0.99x
      > >                 bitmap_RGBA_8888_scale_rotate_bilerp	 103us ->  101us	0.99x
      > >                               bitmap_RGBA_8888_scale	18.4us -> 18.2us	0.99x
      > >              bitmap_RGBA_8888_A_scale_rotate_bicubic	  71us ->   70us	0.99x
      > >          bitmap_RGBA_8888_update_scale_rotate_bilerp	 103us ->  101us	0.99x
      > >               bitmap_RGBA_8888_A_scale_rotate_bilerp	 112us ->  109us	0.98x
      > >                     bitmap_RGBA_8888_update_volatile	5.72us -> 5.58us	0.98x
      > >                                     bitmap_RGBA_8888	5.73us -> 5.58us	0.97x
      > >                              bitmap_RGBA_8888_update	5.78us ->  5.6us	0.97x
      > >                      bitmap_RGBA_8888_A_scale_bilerp	70.7us ->   68us	0.96x
      > >                     bitmap_RGBA_8888_A_scale_bicubic	23.7us -> 21.8us	0.92x
      > >                                   bitmap_RGBA_8888_A	13.9us -> 10.9us	0.78x
      > >                     bitmap_RGBA_8888_A_source_opaque	  14us -> 6.29us	0.45x
      > >                bitmap_RGBA_8888_A_source_transparent	  14us -> 3.65us	0.26x
      > >
      > > Running over our ~70 SKP web page captures, this looks like we spend 0.7x
      > > the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should
      > > be a decent predictor of real-world impact.
      > >
      > > BUG=chromium:399842
      > >
      > > Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785
      > >
      > > CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Release-Trybot
      > >
      > > Committed: https://skia.googlesource.com/skia/+/6dbfb21a6c88af6d94e8c823c3ad559f1a41b493
      >
      > TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > BUG=chromium:399842
      >
      > Committed: https://skia.googlesource.com/skia/+/4988891a1173cd405bf1c1dd3a3668c451f45e4c
      
      TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:399842
      
      Review URL: https://codereview.chromium.org/894083002
      4bf1ce27
    • stephana's avatar
      Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset... · 4988891a
      stephana authored
      Revert of SSE4 opaque blend using intrinsics instead of assembly. (patchset #16 id:300001 of https://codereview.chromium.org/874863002/)
      
      Reason for revert:
      This causes a bug on the 'hittestpath' GM on MacMini 4,1
      
      See:
      
      https://gold.skia.org/#/triage/hittestpath?head=0
      
      for details.
      
      Original issue's description:
      > SSE4 opaque blend using intrinsics instead of assembly.
      >
      > Since we had such a hard time with the assembly versions of this blit (to the
      > point that we have them completely disabled everywhere), I thought I'd take
      > a shot at writing a version of the blit using intrinsics.
      >
      > The key feature of SSE4 we're exploiting is that we can use ptest (_mm_test*)
      > to skip the blend when the 16 src pixels we consider each loop are all opaque
      > or all transparent.  _mm_shuffle_epi8 from SSSE3 also lends a hand to extract
      > all those alphas.
      >
      > It's worth looking to see if we can backport this type of logic to SSE2 using
      > _mm_movemask_epi8, or up to 32 pixels at a time using AVX.
      >
      > My local performance testing doesn't show this to be an unambiguous win
      > (there are probably microbenchmarks and SKPs where we'd be better off just
      > powering through the blend rather than looking at alphas), but the potential
      > does seem tantalizing enough to let skiaperf vet it on the bots.  (< 1.0x is a win.)
      >
      > DM says it draws pixel perfect compare to the old code.
      >
      > Microbenchmarks:
      >                bitmap_RGBA_8888_A_source_stripes_two	  14us -> 14.4us	1.03x
      >              bitmap_RGBA_8888_A_source_stripes_three	14.3us -> 14.5us	1.01x
      >                        bitmap_RGBA_8888_scale_bilerp	61.9us -> 62.2us	1.01x
      > bitmap_RGBA_8888_update_volatile_scale_rotate_bilerp	 102us ->  101us	0.99x
      >                 bitmap_RGBA_8888_scale_rotate_bilerp	 103us ->  101us	0.99x
      >                               bitmap_RGBA_8888_scale	18.4us -> 18.2us	0.99x
      >              bitmap_RGBA_8888_A_scale_rotate_bicubic	  71us ->   70us	0.99x
      >          bitmap_RGBA_8888_update_scale_rotate_bilerp	 103us ->  101us	0.99x
      >               bitmap_RGBA_8888_A_scale_rotate_bilerp	 112us ->  109us	0.98x
      >                     bitmap_RGBA_8888_update_volatile	5.72us -> 5.58us	0.98x
      >                                     bitmap_RGBA_8888	5.73us -> 5.58us	0.97x
      >                              bitmap_RGBA_8888_update	5.78us ->  5.6us	0.97x
      >                      bitmap_RGBA_8888_A_scale_bilerp	70.7us ->   68us	0.96x
      >                     bitmap_RGBA_8888_A_scale_bicubic	23.7us -> 21.8us	0.92x
      >                                   bitmap_RGBA_8888_A	13.9us -> 10.9us	0.78x
      >                     bitmap_RGBA_8888_A_source_opaque	  14us -> 6.29us	0.45x
      >                bitmap_RGBA_8888_A_source_transparent	  14us -> 3.65us	0.26x
      >
      > Running over our ~70 SKP web page captures, this looks like we spend 0.7x
      > the time in S32A_Opaque_BlitRow compared to the SSE2 version, which should
      > be a decent predictor of real-world impact.
      >
      > BUG=chromium:399842
      >
      > Committed: https://skia.googlesource.com/skia/+/04bc91b972417038fecfa87c484771eac2b9b785
      >
      > CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.6-MacMini4.1-GeForce320M-x86_64-Release-Trybot
      >
      > Committed: https://skia.googlesource.com/skia/+/6dbfb21a6c88af6d94e8c823c3ad559f1a41b493
      
      TBR=henrik.smiding@intel.com,mtklein@google.com,herb@google.com,reed@google.com,thakis@chromium.org,mtklein@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:399842
      
      Review URL: https://codereview.chromium.org/873553003
      4988891a
    • bungeman's avatar
      Add resourcePath to running dm on Android doc. · db204e30
      bungeman authored
      Without specifying the resource path a number of tests and gms do not
      work properly. The example given in the docs should specify the
      resource path so that the example run is exemplary.
      
      Review URL: https://codereview.chromium.org/898453003
      db204e30
    • qiankun.miao's avatar
      Optimize SSE2 opaque blend · ad49b3b7
      qiankun.miao authored
      Backport optimization from https://codereview.chromium.org/874863002/.
      Microbenchmarks data compared to previous SSE2 implementation:
                   bitmap_BGRA_8888_A_source_stripes_three    7.52us -> 8.67us        1.15x
                     bitmap_BGRA_8888_A_source_stripes_two    7.48us -> 8.56us        1.15x
               bitmap_BGRA_8888_update_scale_rotate_bilerp    63.4us ->   64us        1.01x
                          bitmap_BGRA_8888_update_volatile    3.31us -> 3.33us        1.01x
                                    bitmap_BGRA_8888_scale    11.1us -> 11.2us        1x
                             bitmap_BGRA_8888_scale_bilerp    35.8us -> 35.9us        1x
                                          bitmap_BGRA_8888    3.33us -> 3.33us        1x
                   bitmap_BGRA_8888_A_scale_rotate_bicubic    66.7us -> 66.5us        1x
      bitmap_BGRA_8888_update_volatile_scale_rotate_bilerp    65.1us ->   64us        0.98x
                      bitmap_BGRA_8888_scale_rotate_bilerp    65.1us ->   64us        0.98x
                          bitmap_BGRA_8888_A_scale_bicubic    30.6us -> 29.9us        0.98x
                           bitmap_BGRA_8888_A_scale_bilerp    42.7us -> 41.4us        0.97x
                    bitmap_BGRA_8888_A_scale_rotate_bilerp      71us -> 67.7us        0.95x
                                        bitmap_BGRA_8888_A    7.44us ->  5.7us        0.77x
                          bitmap_BGRA_8888_A_source_opaque    7.46us -> 3.72us        0.5x
                     bitmap_BGRA_8888_A_source_transparent    7.46us -> 1.96us        0.26x
      
      BUG=skia:
      
      Review URL: https://codereview.chromium.org/886403002
      ad49b3b7
    • fmalita's avatar
      Disable LCD text when rasterizing SkPictureShader tiles. · 3d91aad2
      fmalita authored
      BUG=chromium:453299
      R=reed@google.com
      
      Review URL: https://codereview.chromium.org/884163003
      3d91aad2
    • skia.buildbots's avatar
      Update SKP version · c927918c
      skia.buildbots authored
      Automatic commit by the RecreateSKPs bot.
      
      TBR=
      
      Review URL: https://codereview.chromium.org/890293003
      c927918c
    • reed's avatar
      allow GMs to animate · d9adfe6a
      reed authored
      BUG=skia:
      
      Review URL: https://codereview.chromium.org/888283002
      d9adfe6a
  3. 01 Feb, 2015 4 commits
  4. 31 Jan, 2015 4 commits