This also fixes the C++ side to give the right baseline information.
Previously it was giving the baseline distance for the font, but not
for the actual laid-out text.
I considered also providing a "defaultBaseline" accessor that returns
the distance for the actual dominant baseline, but it turns out right
now we never decide the baseline is ideographic. We always use the
alphabetic baseline. We should probably fix that...
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200233002.
This CL factors the network interactions out of DartLoader into a
DartLibraryProvider interface, paving the way for other library providers
(e.g., offline).
As part of this CL, I've renamed DartLoader to DartLibraryLoader and moved the
class into tonic, where it can't have any direct network dependencies.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1202283004.
This CL adds the ability to load Dart snapshot files created by sky_packager in
Sky. Using a snapshot lets us transmit all the code for an app in a single blob
and should improve startup time. Later CLs will make this codepath easier to
use and evaluate performance.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1197133004.
Previously, the wavy underline code only knew how to draw a complete
period.
This change adds the ability to draw a partial period of the wave.
Previously, the code tried, but failed, for reasons I cannot
determine, to fit the width of the inline by extending the period to
be an integral factor of the width.
This is bad because as you type text, the underline wave of earlier
characters would jiggle.
This fixes that by not changing the period of the wave when the length changes.
It's interesting to compare this to the previous code. Here's a test
that shows this in Safari/Chrome:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3543
Notice how as you type "i"s, the underline changes how far it extends
(obviously a bug) but also what the period of the wave is (which looks
especially ugly when typing).
Firefox, on the other hand, renders something that isn't actually a
wave; it's a saw-tooth pattern with straight lines between each
direction change. This works for small font sizes at low densities,
but is not great on modern screens.
This CL addresses this issue by computing the bezier curve control
points for the curve that consists of just the remaining fraction of
the period. To do this, however, it allocates an object and solves a
bezier for x (which includes a numerical integration), which is
certainly a performance concern. Apps that try to wavy-underline an
entire UI are going to maybe suffer. Since this is typically going to
be used for spelling checkers, it means people who spell better will
have better performance.
(I haven't tested this to see what the perf impact actually is. If
it's actually bad, we can probably cache the results of the
integration pretty trivially.)
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1189403005.
- constructors first
- have either a blank line at the top and bottom of each class, or no blank line in either place (it's still inconsistent about which we should do)
- hide clamp()
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1172173002
This CL implements a basic version of screen rotation where we just relayout at
the new size. In the future, we'll want a fancy version where we transition
between the two layouts.
R=ianh@google.com
BUG=
Review URL: https://codereview.chromium.org/1177563002.
We already know how to talk to the network_service from Dart
via fetch.dart. Might as well use that for Image loading
as well insetad of having ImageLoader do it.
As part of this I've renamed *ImageLoader to *ImageDecoder
and moved all the image loading logic into Dart. This required
me to teach the idl system about mojo handles so that I could
pass the resulting MojoHandle from fetch.dart up through to
ImageDecoder.
R=abarth@chromium.org, jackson@google.com, hansmuller@google.com
Review URL: https://codereview.chromium.org/1173703002.
Rather than appending the custom Foo.dart code to the end of the generated
interface, we now copy it to a CustomFoo.dart file in the output directory.
This allows us to declare it as a proper dependency.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1171743002
This is just another hack on top of the hack that is LayoutRoot.
We will want to untangle Document ownership further as we
iterate on LayoutRoot. For now LayoutRoot is both very
inefficient (allocates a new Frame for each one!) as well
as crashy like this (by not actually owning the document
but rather grabbing it off the "rootElement" assigned to it).
This at least fixes this common crasher for now.
https://github.com/domokit/mojo/issues/206R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1171643002
I had to complicate the IDL bindings generation to allow passing an array of
colors. Without these changes, we'd try to convert the dart object to
Vector<SkColor>, which C++ thinks is Vector<unsigned>, and we'd use the wrong
converter. So I added some template grease to force it to use a
Vector<CanvasColor> converter.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1152963009
