Since we're parsing segment headers for random-access jbig2 inputs
already, just always do that and get the image dimensions from the
PageInformation segment data. Not all that much more code, and it
makes this script much more pleasant to use.
jbig2 data in PDFs is in the embedded organization, which is like the
sequential organization with the file header removed.
That means jbig2 files using the random-access organization need to
be transformed to be supported. A random-access jbig2 has all segment
headers at the start, followed by the data of all segments. Decode
all headers and rewrite them to the sequential organization, where
each segment header is followed by that segment's data.
The motivation is that almost all of the jbig2 files in
ghostpdl/test/jbig2 use the random-access organization.
If the left-hand side of the tab is already occupied with an audio state
button, we would add a second button to the right-hand side. Prevent
that by checking if the occupant is our audio state button.
On Serenity, it's not trivial to extract the peer pid from a socket that
is created by SystemServer and then passed to a forked service process.
This patch adds an API to let the WebContent process notify the UI
directly, which makes the WebContent process show up in the Serenity
port's TaskManagerWidget. It seems that we will need to do something of
this sort in order to properly gather metrics on macOS as well, due to
the way that self mach ports work.
This implementation uses a really basic WebView to update stats once
a second. In the future it might make more sense to both move the
details into LibWebView, and to create a native widget for each platform
to remove the overhead of having an extra WebView.
This avoids the potential for unwanted implicit conversions to bool.
It doesn't prevent if (m_ptr) checks though, as that invokes an explicit
conversion to bool. This is how std::unique_ptr and std::optional work.
We used to expand every bit in an 1bpp image to a 0 or 255 byte,
then map that to a float that's either 0.0f or 1.0f (or whatever's
in /DecodeArray), then multiply that by 255.0f to convert it to a
u8 and put that in the rgb channels of a Color.
Now we precompute the two possible outcomes (almost always Black
and White) and do a per-bit lookup.
Reduces time for
Build/lagom/bin/pdf --render-bench --render-repeats 20 --page 36 \
~/Downloads/Flatland.pdf
(the "decoded data cached" case) from 3.3s to 1.1s on my system.
Reduces time for
Build/lagom/bin/pdf --debugging-stats ~/Downloads/0000/0000231.pdf
(the "need to decode each page" case) from 52s to 43s on my machine.
Also makes paging through PDFs that contain a 1700x2200 pixel CCITT
or JBIG2 bitmap on each page noticeably snappier.
For now, all Resources are implemented with a modification time, but the
public API has been left as an Optional since abstractly, not all
resources will have a modification time.
Previously, we were accessing the performance through the current
window object. Thus caused a crash when `animate()` was called on an
element within a document with no associated window object. The global
object is now used to access the performance object in places where
a window object is not guaranteed to exist.
Once we have built up a cache, we can use that internally for operations
on the collection, instead of copying over the list of elements every
time.
On a synthentic benchmark of a page with ~500 link elements, this
results in a 45% percent speedup on my machine.
```html
<body>
<ul>
<li><a href="#">Link 1</a></li>
...
<li><a href="#">Link N</a></li>
</ul>
<script>
window.onload = function() {
const startTime = performance.now();
for (let i = 0; i < 1_000_000; ++i) {
const numLinks = document.links.length;
}
const endTime = performance.now();
const timeTaken = endTime - startTime;
console.log(timeTaken);
};
</script>
</body>
</html>
```
See the PR adding this test for local changes to `jbig2`.
I used the shell script mentioned in #23659, except I added the line
`-txt -Param -Transposed 1` at the very end of the .ini file.
As with all the symbol test cases, after running
Meta/jbig2_to_pdf.py -o foo.pdf foo.jb2 399 400
the file opens up ok in Chrome and Firefox (but not Safari), so
maybe it's not completely broken.
Only the coordinates get transposed -- the bitmaps apparently don't.
And all the prose amounts to "if the transposed bit is set, swap
instance s and t coordinates before painting", as far as I can tell.
Makes pages 3/4 and 7/8 in 0001346.pdf render. (But here the feature
isn't used to render transposed text -- it just has stripes that keep s
roughy constant, which would normally produce vertical runs but here
produces regular horizontal runs. It's not clear to me why this feature
is used for these pages!)
