Create reference/create a scratch texture from a bitmap only it does not have

A bitmap can be backed by a valid texture.  During when converting
a bitmap to a GrEffect from a bitmap shader, we check whether there is
 a valid texture.  Only create/reference a new texture if bitmap does not
have one.

If there is a texture, we must check whether target driver support npot and
tiling.  If not, we need to create a pot texture, paint orig texture to
pot texture
Do not draw bitmap directly on non-msaa render target

If AA is specified, and the dst rect is not pixel-aligned,
do not draw bitmap on non-msaa render target directly
in drawBitmap(), drawBitmapRect(), drawBitmapRectToRect().  Instead,
we must convert these calls to drawRect() so that it goes to GrAARect or
GrAAConvex renderers.

The exception is bitmap size bigger than max texture size.  In this case,
SkBitmapProcShader cannot handle. we will let drawBitmapCommon to handle
this
Do not optimize draw image if target driver does not support npot

If the target driver does not support npot image, we must create a
pot image, paint the original image to pot image.  In this case,
optimization of image draw does not have much sense because
we have to first draw the pot image. In this case, we disable image
drawing optimization.  Fortunately, most of modern driver (including
es3 drivers) support npot image tiling
Detect the direction of oval while using addOval method in SkPath.

While drawing oval using arcTo method of SkPath, detect the
correct direction of oval whether it is CW or CCW and invoke addOval
method with appropriate direction.
Parallelize SkLightDeferredCanvas:

SkMutex(fCondVar1) manages recording thread and SkCondVar(fCondVar2) manages
the flush and playback thread . fCondVar2 waits in flush recording and playback
upon reading a flush command signals using fCondVar2 thereby releasing the wait.
SkCondVar is replaced with a pthread_cond_t and pthread_mutex_t.
The problem with SkCondVar seems to be that if same fCondVar are
used in playback(fCondVar2.signal()) and flush(fCondVar2.wait()) then
then playback and flush are becoming synchronous leading to a deadlock
when native flashcanvas is used to verify the threaded behavior .
The issue is not encountered when pthread_cond_t and pthread_mutex_t are
used to signal and wait.