This fixes a plethora of rounding problems on many websites.
In the future, we may want to replace this with fixed-point arithmetic
(bug #18566) for performance (and consistency with other engines),
but in the meantime this makes the web look a bit better. :^)
There's a lot more things that could be converted to doubles, which
would reduce the amount of casting necessary in this patch.
We can do that incrementally, however.
This finally makes SVG-as-image show up visually! :^)
We should find a way to share this logic with Layout::SVGSVGBox, but
that will require some finesse since they have to work at different
points in the layout/paint timeline.
In order to separate the SVG content from the rest of the engine, it
gets its very own Page, PageClient, top-level browsing context, etc.
Unfortunately, we do have to get the palette and CSS/device pixel ratios
from the host Page for now, maybe that's something we could refactor in
the future.
Note that this doesn't work visually yet, since we don't calculate the
intrinsic sizes & ratio for SVG images. That comes next. :^)
This allows the painting subsystem to request a bitmap with the exact
size needed for painting, instead of being limited to "just give me a
bitmap" (which was perfectly enough for raster images, but not for
vector graphics).
This implements the stop-opacity, fill-opacity, and stroke-opacity
properties (in CSS). This replaces the existing more ad-hoc
fill-opacity attribute handling.
This follows on from the SVG linear gradients. It supports the same
features (xlink:href, gradientUnits, gradientTransform).
With this commit I have now implemented all web gradients :^)
(Though we are still missing a few parameters for SVG gradients,
e.g. spreadMethod).
This bit is mostly ad-hoc for now. This simply turns fill: url(#grad1)
into document().get_element_by_id('grad1') then resolves the gradient.
This seems to do the trick for most use cases, but this is not
attempting to follow the spec yet to keep things simple.
This represents the SVG <linearGradient>. The actual gradient is
converted to a Gfx::PaintStyle for use in SVG fills... There is a little
guesswork in the implementation, but it seems to match Chrome/Firefox.
Note: Still not hooked up to actual painting in this commit.
This is the base class for all SVG gradient types. This supports:
- The `gradientUnits` attribute
- The `gradientTransform` attribute
- And following `xlink:hrefs` for inheriting <stops>/attributes
Per SVG2, any coordinate pairs following a moveto command should be
treated as implicit lineto commands with the same absoluteness as the
moveto command.
This attribute is used to define how the viewBox should be scaled.
Previously the behaviour implemented was that of "xMidYMid meet", now
all of them work (expect none :P).
With this the Discord login backend is now correctly scaled/positioned.
This also brings our SVG code a little closer to the spec! With spec
comments and all :^)
(Minor non-visible update to layout tests)
This uses the new attribute parser functionality, and then resolves the
transform list into a single Gfx::AffineTransform.
This also adds a .get_transform() function which resolves the final
transform, by applying all parent transforms.
This parses SVG transforms using the syntax from CSS Transforms
Module Level 1. Note: This looks very similar to CSS tranforms, but
the syntax is not compatible. For example, SVG rotate() is
rotate(<a> <x> <y>) where all parameters are unitless numbers whereas
CSS rotate() is rotate(<angle> unit) along with separate rotateX/Y/Z().
(At the same time AttributeParser is updated to use GenericLexer which
makes for easier string matching).
There is work needed for error handling (which AttributeParser does not
deal with very gracefully right now).
Previously we were using the HTML parse_dimension_value method for the
height and width attributes of an SVG element. These attributes should
however be treated as css properties instead and thus also support
calc() and absolute units so we use the css parser for this instead.
These are currently initialized in a [[gnu::constructor]], which has a
weird initialization order. These constructors are invoked before main()
and, incidentally, before any user-defined default constructors of the
static strings they are initializing.
This will become an issue when these strings are ported to FlyString,
which has a user-defined default constructor. In that scenario, when the
FlyString constructor is executed after the [[gnu::constructor]], the
strings will be "reset" to the empty string.
Instead of relying on a non-standard compiler extension here, let's just
initialize these strings explicitly during main-thread VM creation, as
this now happens in WebContent's main().
This class had slightly confusing semantics and the added weirdness
doesn't seem worth it just so we can say "." instead of "->" when
iterating over a vector of NNRPs.
This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
