Instead of just keeping them in an unsorted Vector, which led to
increasingly noticeable O(n) lookups, we now cache a list of Typefaces
per family name.
The previous version relied on manually setting the amount of data to
read for the next chunk and was overall unclear. The new version uses
the Bytes API to vastly improve readability, and fixes a bug where
reading from files where a single read that wasn't of equal size to the
block size would cause the byte buffer to be incorrectly resized causing
corrupted output.
The document.domain setter is currently stubbed as that is a doozy to
implement, given how much restrictions there are in place to try and
prevent use of it and potential multi-process implications.
This was the only thing preventing us from being able to start
displaying ads delivered via Google Syndication.
In a subclass of Cell, we cannot use Cell::vm() before the base Cell
object itself is constructed. Use the Realm's VM instead.
This was caught by UBSAN with vptr sanitation enabled.
IsArray returns true if the object is an Array *or* if it is a
ProxyObject whose target is an Array. Therefore, we cannot downcast to
an Array based on IsArray.
Luckily, we don't actually need an Array here; SerializeJSONArray only
needs an Object.
This was caught by UBSAN with vptr sanitation enabled.
This patch improves @font-face loading when there are multiple src
values in two ways:
- Invalid/empty URLs are ignored
- Fonts with unsupported file extensions are ignored
This makes us load and display the emblem font on modern Reddit,
which is pretty neat! :^)
I don't see any indication in the spec that an empty prelude should be
disallowed. This fixes rules like `@font-face{...}` (note the absence
of whitespace before the `{`.)
When calculating the automatic height of a BFC root, we stretch it to
contain the bottommost margin edge of floating boxes.
Before this change, we assumed that floating boxes had coordinates
relative to the BFC root, when they're actually relative to the floating
box's containing block. This may or may not be the BFC root, so we have
to use margin_box_in_ancestor_coordinate_space() to apply offsets from
all boxes in the containing block chain (up to the BFC root).
On every texel access, some floating point instructions involved in
copying 4 floats popped up. Let `Image::texel() const` return a
`FloatVector4 const&` to prevent these operations.
This results in a ~7% FPS increase in GLQuake on my machine.
Looking at `Tubes` before and after this change, comparing the original
loop to the one using `memcpy`, including the time for `memcpy` itself,
resulted in ~15% fewer samples in profiles on my machine.
In some artificial full screen blitting profiling, I've seen `memcpy`
take up about 4% fewer samples each time I measure. It seems like
`fast_u32_copy` is not as fast as it'd like to believe.
The HTML spec provides a set of suitable default CSS rules for our UA
stylesheet, so let's use those instead of inventing our own. :^)
Note that I had to replace "foo-block-start" properties with "foo-top"
since we don't support the block/inline direction based properties yet.
This is rather subtle and points to our architecture around definite
sizes not being exactly right, but...
At some points during flexbox layout, the spec tells us that the sizes
of certain flex items are considered definite from this point on.
We implement this by marking each item's associated UsedValues as
"has-definite-width/height".
However, this breaks code that tries to resolve computed "auto" sizes
by taking the corresponding size from the containing block. The end
result was that the 1st sizing pass in flexbox would find the right size
for an "auto" sized item, but the 2nd pass would override the correct
size with the containing block's content size in that axis instead.
To work around the issue, FFC now remembers when it "definitizes" an
item, and future attempts to resolve an "auto" computed size for that
value will bypass the computed-auto-is-resolved-against-containing-block
step of the algorithm. It's not perfect, and we'll need to think more
about how to really represent these intermediate states relating to
box sizes being definite..
By asking if the value *contains* a percentage rather than whether it
*is* one, we cover many more cases where e.g `width: calc(100% - 10px)`
should be "treated as auto" etc.
Values that contain percentages require special treatment in various
parts of layout. Previously we had no way of peeking into calc() values
to see if their expression contains one or more percentages. That's the
bulk of what we're adding here.
This does many tweaks to the Source font. The tweaks mainly apply to
the bold weight, but tweaks small things about the Regular weight.
This mainly corrects inconsistencies or the placement of pixels in
a glyph.
I tried to pay a lot of attention to how different code looks in this
font and adapt it to that since that is its main purpose.
This partially adds serialization code for
`CSSFontFaceRule::serialized()` to spec. This is only partially
implemented as some parts of the `@font-face` rule are not implemented
yet.
Now that the positions of each grid item have been calculated, and the
sizes of the individual rows and columns ascertained, can actually
layout the different items.
According to the spec it's necessary to:
1. Layout the cells in the grid
2. Find the sizes of the rows and columns
Since I had started to do this backwards, and as I expand in future
commits, I take here the opportunity to start with a clean state.
The occupation_grid keeps track of which cells in the grid have been
filled out.
Often in the spec they talk about intrinsic_track_sizes and this way can
have a clearer way of checking if a GridTrackSize is indeed an
"intrinsic track size".
Makes it more convenient to create auto GridTrackSizes. I think having
an auto GridTrackSize be defined by an auto Length value kind of
confusing, and this at least helps when creating one.
