MacViews: Implement Force Touch/Mac dictionary lookup for Textfields.

ui/gfx/render_text_harfbuzz.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/gfx/render_text_harfbuzz.h"
 
 #include <limits>
 #include <set>
 
 #include "base/i18n/bidi_line_iterator.h"
@@ skipping 1572 matching lines @@
 internal::TextRunList* RenderTextHarfBuzz::GetRunList() {
   DCHECK(!update_layout_run_list_);
   DCHECK(!update_display_run_list_);
   return text_elided() ? display_run_list_.get() : &layout_run_list_;
 }
 
 const internal::TextRunList* RenderTextHarfBuzz::GetRunList() const {
   return const_cast<RenderTextHarfBuzz*>(this)->GetRunList();
 }
 
+bool RenderTextHarfBuzz::GetDecoratedTextForRange(
+    const Range& range,
+    DecoratedText* decorated_text) const {
+  if (obscured())
+    return false;
+
+  decorated_text->attributes.clear();
+  decorated_text->text = GetTextFromRange(range);
+
+  const internal::TextRunList* run_list = GetRunList();
+  for (size_t i = 0; i < run_list->size(); i++) {

[tapted, 2016/09/26 02:02:31]

What would be necessary to put this on the RenderText interface?

E.g. RenderTextHarfbuzz has a (TextRunList wrapping a) TextRunHarfBuzz, which is
quite similar to a RenderTextMac::TextRun.

Hypothetically... TextRunHarfBuzz and RenderTextMac::TextRun could inherit from
the same base class, and RenderText could require classes inheriting from it to
provide a std::vector<TextRunBase*>. 

But also DecoratedText kinda feels like it should be an "input" to the TextRuns
- not something that's built up from the TextRuns (maybe RenderText should have
a DecoratedText member that it passes to the concrete classes. Perhaps even 

RenderText::ApplyColor(..)
RenderText::ApplyBaselineStyle(..)
RenderText::ApplyStyle(..)
RenderText::ApplyWeight(..)

should all be replaced by 

RenderText::ApplyDecorations(..)

This would be a huge gain to performance, since each ApplyFoo first validates
its range, then invalidates its style (requiring a full layout for subsequent
range validations). 

[karandeepb, 2016/09/26 07:00:08]

Yeah this seems plausible and may allow us to move more code from RTM/RTHB to
the RenderText class. However, I guess this is orthogonal to this CL and can be
explored subsequently. 
Currently RenderText uses the BreakList class to store the style info which is
then provided as an input to the concrete classes to create the text runs. I
think the BreakList class is optimized for this use case. 
Also, I don't see how DecoratedText can act as an input to the concrete classes.
It consists of non-overlapping ranges which have the same styles/font. The font
can only be determined by the concrete classes. Also, if we were to eliminate
the font, I don't see what benefits it offers over the current implementation. 
I think this is only a problem with the ApplyStyle call. You are probably
referring to your comment here -
https://codereview.chromium.org/1953133002/#msg8. As you mentioned, it's
probably because of the comment "Do not change styles mid-grapheme to avoid
breaking ligatures." at
https://cs.chromium.org/chromium/src/ui/gfx/render_text.cc?cl=GROK&gsn=IsVali....
But I am not sure, if validating the range is necessary. To me, this feels
something that should be handled while creating the text runs. The code which
creates the run ensures that a single run has the same style. Can a single
grapheme be split across multiple runs?

Even if it is necessary, it can probably be handled by maintaining a temporary
bool flag and temporary breaklist for the various styles, which can be bound
checked when really necessary, say in EnsureLayout. 

But I don't see how DecoratedText helps with any of this.

[tapted, 2016/09/26 08:07:26]

DecoratedText could allow someone to apply multiple/different styles to multiple
ranges at once. The NSAtributedString beginEditing / endEditing probably exists
for a similar reason.

[karandeepb, 2016/09/26 09:22:07]

Oh ok, so basically providing a way for RenderText clients to change multiple
styles for multiple ranges simultaneously is what you were referring to, with
each ApplyDecoration call probably triggering a relayout, which in turn may also
reduce the state we have to maintain for style invalidation.

+    const internal::TextRunHarfBuzz& run = *run_list->runs()[i];
+
+    const Range intersection = range.Intersect(run.range);
+    DCHECK(!intersection.is_reversed());
+
+    if (!intersection.is_empty()) {
+      // Get range relative to the decorated text.
+      DecoratedText::RangedAttribute attribute(
+          gfx::Range(intersection.start() - range.GetMin(),
+                     intersection.end() - range.GetMin()),
+          run.font);
+      attribute.weight = run.weight;
+      attribute.underline = run.underline;
+      attribute.italic = run.italic;
+      attribute.strike = run.strike;
+      attribute.diagonal_strike = run.diagonal_strike;
+      decorated_text->attributes.push_back(attribute);
+    }
+  }
+  return true;
+}
+
 }  // namespace gfx