author Alexis Beingessner <>
Mon, 19 Jun 2017 10:58:28 -0400
changeset 424982 564959d26e8db243ded3d57380842620e60e89e7
parent 1 9b2a99adc05e53cd4010de512f50118594756650
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

Please be apprised of the following Legal Notices:

A) The U.S. District Court for the Eastern District of Virginia has
ruled that the Netscape Navigator code does not infringe Wang's U.S.
Patent No. 4,751,669 ("the '669 Patent") because: 1) HTML is not
Videotex as defined by the '669 patent; 2) web servers are not central
suppliers; and 3) Navigator does not "connect," as defined by the '669
Patent, to web servers on the Internet. Wang may appeal this decision to
the Federal Circuit. Wang contended that its Patent disclosing a
"Videotex" system, is infringed by the following functionality in the
Netscape Navigator code: 1) the animated logo and status line indicators
--See Claims 1,8 and 9; 2) the "File Save As" function --See Claims
23-27; 3) Bookmarks and Rename Bookmarks in the Properties window --See
Claims 20-22; 4) storing HTML, GIF, and JPEG files and adding filename
extensions --See Claim 38

B) Intermind owns pending U.S. patent applications on communications
systems which employ metadata ("channel objects") to define a control
structure for information transfer. The Netscape code does not infringe
as released; however, modifications which utilize channel objects as
described by Intermind should be considered carefully. The following is
a statement from Intermind: "Intermind's claims fundamentally involve
the use of a control structure to automate communications. ...The
essence of Intermind's top claim is that two devices sender and receiver
have persistent storage, communicate over a network, and exchange a
control structure including metadata which describes: 1) what
information is to be updated, 2) when to update this information, and 3)
how to transfer the updated information. In addition, at least the
receiving device must be able to process the metadata in order to
perform the update determination and transfer. Any digital
communications system which incorporates all of these elements will be
covered by Intermind's patents." See

C) Stac, Inc., and its licensing agent Hi/fn, own several patents which
disclose data compression methods implementing an LZS compression
algorithm, including U.S. Patent Nos. 4,701,745 and 5,016, 009 ("the
Stac Patents"). The Netscape Communicator code does not perform
compression. If you modify the Netscape source code to perform
compression, please take notice of the Stac Patents.

D) Netscape Communications Corporation ("Netscape") does not guarantee
that any source code or executable code available from the
domain is Year 2000 compliant.