When this feature was finally merged, the serenity_option in
lagom_options.cmake had the unintended side effect of always setting the
cache variable to "" in the initial cache. In order to actually set the
linker to use to be lld or mold, we need to set with the FORCE flag in
the use_linker.cmake file.
Found by checking with the CMake variable_watch() function.
This will stop the build from spamming the "Using LLD to link Lagom"
message all over the place :^)
The original doc comment was mistakenly copy-pasted from
count_leading_zeroes_safe, and incorrect. The function is doing
something else: it's counting _trailing_ zeroes instead of _leading_
ones.
Do this with INSTALL_INTERFACE genex include directory rules. We should
really standardize where the generated headers *actually* get installed
to though.
The mentioned functions used m_size / 8 instead of size_in_bytes()
(division with ceiling rounding mode), which resulted in an off-by-one
error such that the functions didn't search in the last not-fully-8-bits
byte.
Using size_in_bytes() instead of m_size / 8 fixes this.
Previously, every time a page switched fonts, we'd completely
re-parse the font.
Now, we cache fonts in Renderer, effectively caching them per page.
It'd be nice to have an LRU cache across pages too, but that's a
bigger change, and this already helps a lot.
Font size is part of the cache key, which means we re-parse the same
font at different font sizes. That could be better too, but again,
it's a big help as-is already.
Takes rendering the 1310 pages of the PDF 1.7 reference with
Build/lagom/bin/pdf --debugging-stats \
~/Downloads/pdf_reference_1-7.pdf
from 71 s to 11s :^)
Going through pages especially in the index is noticeably snappier.
(On the PDF 2.0 spec, ISO_32000-2-2020_sponsored.pdf, it's less
dramatic: From 19s to 16s.)
This allows the decoder to fail gracefully when reading a partial or
malformed TBSCertificate. We also now ensure that the certificate data
is valid before making a copy of it.
493dd5d93c caused the `::before`
pseudo-element node to be inserted before the element's content, which
caused issues with how we determine where to insert inline nodes into
the layout tree. At the time, I noticed the issue with contents of flex
containers, and prevented them from merging into a `::before` box.
However, a similar situation happens when we're not in a flex container,
but the pseudo-element has `display: block`. This commit fixes that
situation by using the same logic in both places, so a similar mistake
can't be made again.
This fixes the tab text being invisible on GitHub project pages. :^)
I broke this when moving from a xib file to creating the UI in code.
https://developer.apple.com/documentation/appkit/nsuserinterfaceitemidentification/1396829-identifier
says:
"Identifiers are used during window restoration operations to uniquely
identify the windows of the application. [...] If you create an item in
Interface Builder and do not set a value for this string, a unique value
is created for the item when the nib file is loaded. For
programmatically created views, you typically set this value after
creating the item but before adding it to a window."
Without this, encodeRestorableStateWithCoder: / restoreStateWithCoder:
in MacPDFView weren't getting called.
The documentation is very loud about cell-based things being
deprecated, but it's fairly hidden what to actually do to switch to
the non-deprecated way (implement a certain delegate method).
Session 120 from WWDC 2011 has some notes on this. Apple's official
site no longer seems to have that, but it's e.g. here:
https://docs.huihoo.com/apple/wwdc/2011/session_120__view_based_nstableview.pdf
Just setting headerView to nil removes the header, but also has
the effect of no longer drawing the outline view with a sidebar
background ¯\_(ツ)_/¯.
But also setting drawsBackground to NO on the scroll view restores
the sidebar look, so do that too.
With this, it is no longer necessar to explicitly set style.
The default NSTableViewStyleAutomatic now seems to resolve to
NSTableViewStyleSourceList, so stop explicitly setting it.
(This part has no behavior change.)
Clicking an item in the outline now opens that page.
This requires giving the outline view a delegate, which for some
reason also has th effect of indenting expandable items ¯\_(ツ)_/¯
The vertical alignment of text still looks off, though.
The outline has drawing artifacts, but it is somewhat functional:
You can click on disclosure triangles to open outline items, and
if the outline doesn't fit in the sidebar, it's scrollable.
The outline view has the correct sidebar look: gray with a slightly
transparent glass effect.
Clicking items doesn't have an effect yet.
Previously, `load_from_memory()` just took a raw pointer to the data,
and then manually calculated offsets from that pointer. Instead, let's
use the MappedFile we already have, to stream in the data, to make
things a bit safer. We also now check that the entire file's data was
read, since if there was data left over, then either the file is bad or
we've done something wrong.
I've moved the code directly into `try_load_from_mapped_file()` since
`load_from_memory()` was only called from there. The extra indirection
wasn't adding anything.
When working with FixedMemoryStreams, and especially MappedFiles, you
may don't want to copy the underlying data when you read from the
stream. Pointing into that data is perfectly fine as long as you know
the lifetime of it is long enough.
This commit adds a couple of methods for reading either a single value,
or a span of them, in this way. As noted, for single values you sadly
get a raw pointer instead of a reference, but that's the only option
right now.
GitHub allows relative paths to be used to display images, this should
make the image continue working even when viewing the README from an
earlier commit of the repo in case the location of screenshots is moved.
This is also just a cleaner way to do this.
Turns out this was hurting performance instead of helping it.
By removing the inline capacity, we shrink the size of ExecutionContext
by 512 bytes, which substantially reduces the stack pressure created by
JS recursion (each call creates a new ExecutionContext on the stack).
4.4% speed-up on the entire Kraken benchmark :^)
Previously every file that included Executable.h (which is pretty much
most LibJS and LibHTML files, given that VM.h needs it) had the whole
definition of LibRegex, which was slowing down source parsing.
Window.h is a rather heavy file, so let's try not to include it in
header files when we can!
Element.h now also includes LibWeb/Bindings/Intrinsics.h, but that's
just out of my laziness. Most if not all objects call
`Bindings::ensure_web_prototype<>()` anyway, so I don't think we would
gain much by sticking the header to source files instead.
