I opened Tests/LibGfx/test-inputs/png/wide-gamut-only.png in
Preview.app and used File->Export as PDF... to convert it to a PDF.
I then ran
mutool clean -d Tests/LibPDF/wide-gamut-only.pdf \
Tests/LibPDF/wide-gamut-only.pdf
to decompress it, edited by hand to remove padding around the image
and shrunk the page's MediaBox to be as big as the image, and ran the
command above again to fix up binary offsets in the xref table.
I created a 16-bpp RGB file in Display P3 in photoshop, filled it
with (0, 255, 0), and then drew something on it with (100, 255, 0).
(Since it's a 16-bpp image, 255 ix stored as 0xffff and 100 is stored
as 65535 * 100 / 255 == 0x6464 in the file.)
I verified that Edit->Convert to Profile...->sRGB resulted in an
image filled with (0, 255, 0) in that color space (due to gamut
clipping).
Similar to these:
* https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png
* https://www.dropbox.com/s/tgarynpj65ouafd/insta-logo.png?dl=1
...but in green instead of in red, and hand-drawn by me so no license
concerns.
These allow column-wise, traditional scanline, or random pixel flooding.
Depending on the use case and amount of contestion, any of the
strategies may work best, as tested on 37c3.
Very contested servers are likely to cause EAGAIN socket errors on the
client. Since these errors are not supposed to be fatal, just try
sending the pixel again.
This was tested successfully against massively contested 37c3 pixelflut
servers.
Instead of trying to acquire from an individual mouse device, let's read
from /dev/input/mice, where all mouse packets are blended together from
all mouse devices that are attached to the machine.
This device will be used by userspace to read mouse packets from all
mouse devices that are attached to the machine.
This change is a preparation before we can enable seamless hotplug
capabilities in WindowServer for mouse devices, without any major change
on the userspace side.
Because of this the unary operations got applied to the result of the
operation-in-progress instead of the current argument as shown here:
`16 + 9 <sqrt> =`
Previous output: `sqrt(16 + 9)` = `5`
Expected output: `16 + sqrt(9)` = `19`
We do this by implementing the following fixes:
- The Key_Plus is assigned to a proper map entry index now which is 0x4e
both on the keypad and non-keypad keys.
- Shift+Q now prints out "Q" properly on scan code set 2.
- Key BackSlash (or Pipe on shift key being pressed down) is now working
properly as well.
- Key_Pipe (which is "|" for en-US layout) is now working in scan code
set 2.
- Numpad keys as well as the decimal separator key are working again.
Instead of spawning these processes from the WebContent process, we now
create them in the Browser chrome.
Part 1/N of "all processes are owned by the chrome".
This patch makes a few changes to the way we calculate line-height:
- `line-height: normal` is now resolved using metrics from the used
font (specifically, round(A + D + lineGap)).
- `line-height: calc(...)` is now resolved at style compute time.
- `line-height` values are now absolutized at style compute time.
As a consequence of the above, we no longer need to walk the DOM
ancestor chain looking for line-heights during style computation.
Instead, values are inherited, resolved and absolutized locally.
This is not only much faster, but also makes our line-height metrics
match those of other engines like Gecko and Blink.
Fetching the viewport rect is currently somewhat expensive, since it
requires finding the navigable the document is active in.
We can avoid the cost of repeated calls by simply allowing StyleComputer
to cache the viewport rect at the start of style computation.
This is not necessary, as pressing Enter will activate the button
whether it is in focus or not. This makes the equals button behave the
same as all other buttons.
A bit faster:
```
N Min Max Median Avg Stddev
x 50 0.97179127 1.0031381 0.98313618 0.98407591 0.0092019442
+ 50 0.95996714 0.99507213 0.96965885 0.97242294 0.0095455053
Difference at 95.0% confidence
-0.011653 +/- 0.00372012
-1.18415% +/- 0.378032%
(Student's t, pooled s = 0.0093753)
```
All ColorSpace subclasses converted to float anyways, and this
allows us to save lots of float->Value->float conversions during
image color space processing.
A bit faster:
```
N Min Max Median Avg Stddev
x 50 0.99054313 1.0412271 0.99933481 1.0052408 0.012931916
+ 50 0.97073889 1.0075941 0.97849107 0.98184034 0.0090329046
Difference at 95.0% confidence
-0.0234004 +/- 0.00442595
-2.32785% +/- 0.440287%
(Student's t, pooled s = 0.0111541)
```
According to ministat, a bit faster to render page 3 of 0000849.pdf:
```
N Min Max Median Avg Stddev
x 50 1.000875 1.0427601 1.0208509 1.0201902 0.01066116
+ 50 0.99707389 1.03614 1.0084391 1.0107864 0.010002724
Difference at 95.0% confidence
-0.00940384 +/- 0.0041018
-0.921773% +/- 0.402062%
(Student's t, pooled s = 0.0103372)
```
Microoptimization; according to ministat a bit faster:
```
N Min Max Median Avg Stddev
x 50 1.0179932 1.0561159 1.0315337 1.0333617 0.0094757426
+ 50 1.000875 1.0427601 1.0208509 1.0201902 0.01066116
Difference at 95.0% confidence
-0.0131715 +/- 0.00400208
-1.27463% +/- 0.387287%
(Student's t, pooled s = 0.0100859)
```
This is a normative change in the ECMA-262 spec. See:
https://github.com/tc39/ecma262/commit/22de374
The issue noted here has been fixed in the same way that we previously
worked around it. Update the spec notes to match.
We have two known PlatformObjects that need to implement some of the
behavior of LegacyPlatformObjects to date: Window, and HTMLFormElement.
To make this not require double (or virtual) inheritance of
PlatformObject, move the behavior of LegacyPlatformObject into
PlatformObject. The selection of LegacyPlatformObject behavior is done
with a new bitfield of feature flags instead of a dozen virtual
functions that return bool. This change simplifies every class involved
in the diff with the notable exception of Window, which now needs some
ugly const casts to implement named property access.
Without a key function, the vtable for this class can be emitted into
every shared object or executable that needs it. This can cause bugs and
bad behavior when trying to access the vtable or RTTI for the class.
This is most easily seen when trying to call ``is<JS::Date>``, which
currently will do a dynamic_cast. Based on compiler, linker and loader
choices about ordering, it's possible that the code checking the RTTI
and the code that created the object could have a different vtable and
type_info in mind, causing false negatives for the ``is`` check.
Reduces time spent rendering page 3 of 0000849.pdf from 1.32s to 1.13s
on my machine.
Also reduces the time to run Meta/test_pdf.py on 0000.zip
(without 0000849.pdf) from 56s to 54s.
Previously, some non-default process statistics were displayed in a
long human readable format in the processes tab, which could negatively
affect readability. A shorter format is now used in the processes tab,
while the process properties window retains the longer format.
Before the key events for shortcuts such as ALT-F4 did not work as the
widget was swallowing up the shortcut. This changes ignores the event
if nothing else matched
