The main meat of things is in SkThreadPool. We can now give SkThreadPool a
type for each thread to create and destroy on its local stack. It's TLS
without going through SkTLS.
I've split the DM tasks into CpuTasks that run on threads with no TLS, and
GpuTasks that run on threads with a thread local GrContextFactory.
The old CpuTask and GpuTask have been renamed to CpuGMTask and GpuGMTask.
Upshot: default run of out/Debug/dm goes from ~45 seconds to ~20 seconds.
BUG=skia:
R=bsalomon@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/179233005
git-svn-id: http://skia.googlecode.com/svn/trunk@13632 2bbb7eff-a529-9590-31e7-b0007b416f81
*** SKP format breaking change ***
Adding a couple of culling primitives: pushCull(SkRect) & popCull().
These are currently only plumbed for SKP playback quickreject.
At record time, we perform a couple of optimizations to trim down the
number of redundant culls:
* collapse empty pushCull/popCull pairs
* skip pushCull/popCull pairs nested within an identical cull rect
Things still missing/to consider:
* use an inlineable, simplified quickreject (Mike's old prototype)
* debugger visualization for cull boxes
* BBH integration: the initial prototype had some minimal BBH support,
but since the optimizations required expensive rewinds and culling
is expected to be a BBH alternative, it got dropped.
R=bsalomon@google.com, reed@google.com, robertphillips@google.com, caryclark@google.com, tomhudson@google.com, iancottrell@google.com
Author: fmalita@chromium.org
Review URL: https://codereview.chromium.org/138013009
git-svn-id: http://skia.googlecode.com/svn/trunk@13611 2bbb7eff-a529-9590-31e7-b0007b416f81
This patch includes a modified version of Chrome's trace_event.h, which provides
tracing macros that can easily integrate into the about://tracing framework.
Currently the macros link to a default implementation of the (narrow) tracing
class SkDefaultEventTracer which does nothing; next step will be to have Chrome
subclass the SkEventTracer with a shim that bolts Skia's trace events to its own,
allowing Skia's trace events to show up in about://tracing.
I've verified that this file builds properly, and when I added a simple scoped
TRACE_EVENT0 to SkCanvas::drawRect, along with some debug prints in the NOP
implementation of tracing, I saw what I expected printed to the screen.
BUG=skia:
R=nduca@chromium.org, reed@google.com, mtklein@google.com, bsalomon@google.com
Author: humper@google.com
Review URL: https://codereview.chromium.org/149563004
git-svn-id: http://skia.googlecode.com/svn/trunk@13256 2bbb7eff-a529-9590-31e7-b0007b416f81
Eliminates SkFlattenable{Read,Write}Buffer, promoting SkOrdered{Read,Write}Buffer
a step each in the hierarchy.
What used to be this:
SkFlattenableWriteBuffer -> SkOrderedWriteBuffer
SkFlattenableReadBuffer -> SkOrderedReadBuffer
SkFlattenableReadBuffer -> SkValidatingReadBuffer
is now
SkWriteBuffer
SkReadBuffer -> SkValidatingReadBuffer
Benefits:
- code is simpler, names are less wordy
- the generic SkFlattenableFooBuffer code in SkPaint was incorrect; removed
- write buffers are completely devirtualized, important for record speed
This refactoring was mostly mechanical. You aren't going to find anything
interesting in files with less than 10 lines changed.
BUG=skia:
R=reed@google.com, scroggo@google.com, djsollen@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/134163010
git-svn-id: http://skia.googlecode.com/svn/trunk@13245 2bbb7eff-a529-9590-31e7-b0007b416f81
SkGraphics::Init() now checks to see if there are any non-default
runtime configuration options before announcing that it is about
to print out the non-default runtime configuration options.
This makes the executables in tools/ less verbose.
Add SkRTConfRegistry::countNonDefault() function.
BUG=
R=mtklein@google.com, reed@google.com
Review URL: https://codereview.chromium.org/133583003
git-svn-id: http://skia.googlecode.com/svn/trunk@13017 2bbb7eff-a529-9590-31e7-b0007b416f81
While it doesn't matter on Windows, mingw on case-sensitive OSes uses all lower case filenames for platform include files. I found the problem in SkCondVar.h from Mozilla checkout of skia sources, but the patch contains a fix for the whole skia tree.
R=bungeman@google.com
Review URL: https://codereview.chromium.org/99173003
git-svn-id: http://skia.googlecode.com/svn/trunk@12461 2bbb7eff-a529-9590-31e7-b0007b416f81
SK_CONF_TRY_SET() is like SK_CONF_SET(), but doesn't complain if
confname can't be found. This is useful if the SK_CONF_DECLARE is
inside a source file whose linkage is dependent on the system.
Internally to the SkRTConf system, SkRTConfRegistry::set() was given
an additional parameter controling wanrings.
A new RuntimeConfig unit test was introduced. It should run silently.
In the future, it should be expanded to cover all of the SkRTConf
functionality.
(For example, the images.jpeg.suppressDecoderWarnings variable is
defined and used only in SkImageDecoder_libjpeg.cpp, but on MacOS, we
use Core Graphics via SkImageDecoder_CG.cpp - SkImageDecoder_libjpeg
is never linked in. The same is true of the Windows Imaging Component
on Windows.)
BUG=
R=reed@google.com
Review URL: https://codereview.chromium.org/54503007
git-svn-id: http://skia.googlecode.com/svn/trunk@12155 2bbb7eff-a529-9590-31e7-b0007b416f81
There's a scenario that we're currently not allowing for, but I'd really like to use in DM:
1) client calls add(SomeRunnable*) several times
2) client calls wait()
3) any of the runnables added by the client _themselves_ call add(SomeOtherRunnable*)
4-inf) maybe those SomeOtherRunnables too call add(SomeCrazyThirdRunnable*), etc.
Right now in this scenario we'll assert in debug mode in step 3) when we call
add() and we're waiting to stop, and do strange unspecified things in release
mode.
The old threadpool had basically two states: running, and waiting to stop. If
a thread saw we were waiting to stop and the queue was empty, that thread shut
down. This wasn't accounting for any work that other threads might be doing;
potentially they were about to add to the queue.
So now we have three states: running, waiting, and halting. When the client
calls wait() (or the destructor triggers), we move into waiting. When a thread
notices we're _really_ done, that is, have an empty queue and there are no
active threads, we move into halting. The halting state actually triggers the
threads to stop, which wait() is patiently join()ing on.
BUG=
R=bungeman@google.com, bsalomon@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/26389005
git-svn-id: http://skia.googlecode.com/svn/trunk@11852 2bbb7eff-a529-9590-31e7-b0007b416f81
