author Alexis Beingessner <>
Mon, 19 Jun 2017 10:58:28 -0400
changeset 424982 564959d26e8db243ded3d57380842620e60e89e7
parent 304505 582ecb12478ae567b439bb5aa01a1ac3b9551e61
child 451029 3d28ca7c05d8f9ba3ba6ff1cd5449dce42ae95c1
permissions -rw-r--r--
Bug 1357545 - handle text-shadows/decorations with webrender (layers-free) r=jrmuizel This replaces our DrawTargetCapture hack with a similar but more powerful TextDrawTarget hack. The old design had several limitations: * It couldn't handle shadows * It couldn't handle selections * It couldn't handle font/color changes in a single text-run * It couldn't handle decorations (underline, overline, line-through) Mostly this was a consequence of the fact that it only modified the start and end of the rendering algorithm, and therefore couldn't distinguish draw calls for different parts of the text. This new design is based on a similar principle as DrawTargetCapture, but also passes down the TextDrawTarget in the drawing arguments, so that the drawing algorithm can notify us of changes in phase (e.g. "now we're doing underlines"). This also lets us directly pass data to TextDrawTarget when possible (as is done for shadows and selections). In doing this, I also improved the logic copied from ContainsOnlyColoredGlyphs to handle changes in font/color mid-text-run (which can happen because of font fallback). The end result is: * We handle all shadows natively * We handle all selections natively * We handle all decorations natively * We handle font/color changes in a single text-run * Although we still hackily intercept draw calls * But we don't need to buffer commands, reducing total memcopies In addition, this change integrates webrender's PushTextShadow and PushLine APIs, which were designed for this use case. This is only done in the layerless path; WebrenderTextLayer continues to be semantically limited, as we aren't actively maintaining non-layers-free webrender anymore. This also doesn't modify TextLayers, to minimize churn. In theory they can be augmented to support the richer semantics that TextDrawTarget has, but there's little motivation since the API is largely unused with this change. MozReview-Commit-ID: 4IjTsSW335h

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-
 * vim: sw=2 ts=2 et lcs=trail\:.,tab\:>~ :
 * This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at */

#ifndef mozStorageBindingParams_h
#define mozStorageBindingParams_h

#include "nsCOMArray.h"
#include "nsIVariant.h"
#include "nsInterfaceHashtable.h"

#include "mozStorageBindingParamsArray.h"
#include "mozStorageStatement.h"
#include "mozStorageAsyncStatement.h"
#include "Variant.h"

#include "mozIStorageBindingParams.h"
#include "IStorageBindingParamsInternal.h"

namespace mozilla {
namespace storage {

class BindingParams : public mozIStorageBindingParams
                    , public IStorageBindingParamsInternal

   * Locks the parameters and prevents further modification to it (such as
   * binding more elements to it).
  void lock();

   * Unlocks the parameters and allows modification to it again.
   * @param aOwningStatement
   *        The statement that owns us.  We cleared this when we were locked,
   *        and our invariant requires us to have this, so you need to tell us
   *        again.
  void unlock(Statement *aOwningStatement);

   * @returns the pointer to the owning BindingParamsArray.  Used by a
   *          BindingParamsArray to verify that we belong to it when added.
  const mozIStorageBindingParamsArray *getOwner() const;

  BindingParams(mozIStorageBindingParamsArray *aOwningArray,
                Statement *aOwningStatement);
  virtual ~BindingParams() {}

  explicit BindingParams(mozIStorageBindingParamsArray *aOwningArray);
  // Note that this is managed as a sparse array, so particular caution should
  // be used for out-of-bounds usage.
  nsTArray<RefPtr<Variant_base> > mParameters;
  bool mLocked;


   * Track the BindingParamsArray that created us until we are added to it.
   * (Once we are added we are locked and no one needs to look up our owner.)
   * Ref-counted since there is no invariant that guarantees it stays alive
   * otherwise.  This keeps mOwningStatement alive for us too since the array
   * also holds a reference.
  nsCOMPtr<mozIStorageBindingParamsArray> mOwningArray;
   * Used in the synchronous binding case to map parameter names to indices.
   * Not reference-counted because this is only non-null as long as mOwningArray
   * is non-null and mOwningArray also holds a statement reference.
  Statement *mOwningStatement;
  uint32_t mParamCount;

 * Adds late resolution of named parameters so they don't get resolved until we
 * try and bind the parameters on the async thread.  We also stop checking
 * parameter indices for being too big since we just just don't know how many
 * there are.
 * We support *either* binding by name or binding by index.  Trying to do both
 * results in only binding by name at sqlite3_stmt bind time.
class AsyncBindingParams : public BindingParams
  NS_IMETHOD BindByName(const nsACString & aName,
                                      nsIVariant *aValue);
  NS_IMETHOD BindByIndex(uint32_t aIndex, nsIVariant *aValue);

  virtual already_AddRefed<mozIStorageError> bind(sqlite3_stmt * aStatement);

  explicit AsyncBindingParams(mozIStorageBindingParamsArray *aOwningArray);
  virtual ~AsyncBindingParams() {}

  nsInterfaceHashtable<nsCStringHashKey, nsIVariant> mNamedParameters;

} // namespace storage
} // namespace mozilla

#endif // mozStorageBindingParams_h