| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This means the units are defined in a single place instead of two.
Also removed the verify that we didn't produce a bogus % dimension token
in the Tokenizer, since this has never happened and the parser is not a
tokenizer test suite. :^)
|
|
This corresponds to `<time>` in the grammar.
|
|
This corresponds to `<resolution>` in the grammar.
|
|
This corresponds to `<frequency>` in the grammar.
|
|
This corresponds to `<angle>` in the grammar.
|
|
We were ignoring this in a couple of places.
|
|
|
|
These will require some tweaking here and elsewhere in LibGUI, to handle
both rendering of the emojis as single glyphs consistently, and faking
key events with multiple code points after selecting one.
|
|
This was getting way too crowded again. Let's just fix the FIXME. :^)
|
|
I'm sure there's a spec for this somewhere, but this is a first working
approximation.
Closes #3315.
|
|
This necessitates switching from passing a single code point to the
callback to passing a non-const Utf8CodePointIterator instead.
Note that the text selection mechanisms in LibGUI and LibWeb don't
handle this properly yet; they still assume that each code point
renders as one glyph. Similarly, width calculations for text widths
don't either, so a single such an emoji will require space for more
than one glyph.
It also doesn't work in LibVT's TerminalWidget, where each code point
is handled and rendered separately, so LibGfx never gets a chance to
check if subsequent code points could result in a combined emoji.
|
|
In the common case of text rendering rather than getting the emoji
bitmap for a fixed number of code points, we don't know how many code
points make one emoji. As far as I can tell, the longest ones are up to
ten code points, so we try to consume all of them and do a lookup during
each iteration, and return the emoji for the longest chain of code
points. Quite basic and definitely room for improvement, but it works!
|
|
Not all emojis are just one code point, so the existing API is not
sufficient: Emoji::emoji_for_code_point(u32).
The file name for such emojis is simply each U+XXXX separated by an
underscore.
|
|
Different thread highlights between widgets lead to different
visual weights between splitters, even when they have the same
width or height. This means some splitters look best at odd
sizes while others even. This sets the default spacing to the
most commonly used, depending on orientation, and adjusts
spacing for a few apps based on the new paint rect.
The most consistent look across apps requires some manual
tweaking occassionally. Knurlheads, use your discretion!
|
|
Splitters could be resized in such an order that all their remaining
children were fixed size, leading to unfillable gaps on resize events.
HackStudio and TextEditor already had logic to handle this edge case,
so this patch factors it into a general solution for all Splitters.
At least one widget is now guaranteed to be resizeable after a child
is removed.
|
|
This gives Splitters more versatility when the right resizee is
intended to remain fixed or be toggled on and off.
|
|
Previously, the rect began on the edge of the first widget instead of
immediately after, causing an overpaint visible on hover.
|
|
This will verify that the signature of the ephemeral key used in the
DHE and ECDHE key exchanges is actually generated by the server.
This verification is done using the first certificate provided by the
server, however the validity of this certificate is not checked here.
Instead this code expects the validity to be checked earlier by
`TLSv12::handle_certificate`.
|
|
This add an implementation for the EMSA-PKCS1-V1_5-ENCODE function from
RFC8017 section 9.2. The verification of this encoding is implemented by
simply encoding the message to be verified, and then comparing the two
encoded string.
The digest info for the different hash function is from RFC8017 section
9.2 notes 1. These byte sequences are actually ASN.1 encoded data,
however these are always constant for a specific hash function and can
be treated as opaque byte sequences.
|
|
NotUnderstood will generate a TLS alert with an InternalError instead of
crashing the RequestServer.
|
|
|
|
|
|
Previously, the names of declarations where stored as a simple
StringView.
Because of that, we couldn't parse out-of-line function definitions,
which have qualified names.
For example, we couldn't parse the following snippet:
```
void MyClass::foo(){}
```
To fix this, we now store the name of a declaration with a
ASTNode::Name node, which represents a qualified named.
|
|
We were erroneously setting the projection matrix when `GL_MODELVIEW`
was supplied.
|
|
Do not convert to float too early. Additionally, handle some error
cases for the input parameters.
|
|
|
|
Our API still specifies it as a double, but internally we communicate a
float to the rasterizer. Additionally, clamp the value to 0..1 as
described in the spec.
|
|
Our implementation keeps the top-most item on the matrix stacks in a
member variable, so we can always use that instead of considering the
actual stack.
Additionally, the current matrix mode should not influence retrieving
the projection or model view matrix.
|
|
No functional changes.
|
|
This fixes the issue where e.g. `299.97` would be cast to an integer
value of `299`, whereas the pixel's center would lie at `299.5` and
would then erroneously be excluded.
|
|
Currently, LibSoftGPU is still OpenGL-minded in that it uses a
coordinate system with the origin of `(0, 0)` at the lower-left of
textures, buffers and window coordinates. Because we are blitting to a
`Gfx::Bitmap` that has the origin at the top-left, we need to flip the
Y-coordinates somewhere in the rasterization logic.
We used to do this during conversion of NDC-coordinates to window
coordinates. This resulted in some incorrect behavior when
rasterization did not pass through the vertex transformation logic,
e.g. when calling `glDrawPixels`.
This changes the coordinate system to OpenGL's throughout, only to blit
the final color buffer upside down to the target bitmap. This fixes
drawing to the depth buffer directly resulting in upside down images.
|
|
No functional changes.
|
|
|
|
|
|
We get `double`s as input, so convert them to `float` first.
|
|
Between the OpenGL client and server, a lot of data type and color
conversion needs to happen. We are performing these conversions both in
`LibSoftGPU` and `LibGL`, which is not ideal. Additionally, some
concepts like the color, depth and stencil buffers should share their
logic but have separate implementations.
This is the first step towards generalizing our `LibSoftGPU` frame
buffer: a generalized `Typed3DBuffer` is introduced for arbitrary 3D
value storage and retrieval, and `Typed2DBuffer` wraps around it to
provide in an easy-to-use 2D pixel buffer. The color, depth and stencil
buffers are replaced by `Typed2DBuffer` and are now managed by the new
`FrameBuffer` class.
The `Image` class now uses multiple `Typed3DBuffer`s for layers and
mipmap levels. Additionally, the textures are now always stored as
BGRA8888, only converting between formats when reading or writing
pixels.
Ideally this refactor should have no functional changes, but some
graphical glitches in Grim Fandango seem to be fixed and most OpenGL
ports get an FPS boost on my machine. :^)
|
|
|
|
This function was added as a FIXME but was then arbitrarily invoked in
the rest of `Device`. We are better off removing this FIXME for now and
reevaluate introducing multithreading later on, so the code is not
littered with useless empty function calls.
|
|
|
|
Let's not do a `float -> double -> float` roundtrip. :^)
|
|
We check for primitive support in `glEnd()`, so we do not need to
preemptively reject the mode in `glBegin()`. This allows `glBegin()` to
be invoked with `GL_POINTS`, for example.
|
|
As there's a somewhat active development going on, let's keep the
expected behaviour under tests to make sure nothing blows up :^)
|
|
'ExpectationError' is hardly an actionable error message.
|
|
Unlike all the other CSS properties, 'float' is special, and can only be
accessed via 'cssFloat' on CSSStyleDeclaration. So this patch adds
support for that. 1 point on ACID3! :^)
|
|
This is what the spec wants us to do.
|
|
This necessitated making HTMLParser ref-counted, and having it register
itself with Document when created. That makes it possible for scripts to
add new input at the current parser insertion point.
There is now a reference cycle between Document and HTMLParser. This
cycle is explicitly broken by calling Document::detach_parser() at the
end of HTMLParser::run().
This is a huge progression on ACID3, from 31% to 49%! :^)
|
|
When calculating how much space is available for inline content between
left and right floated elements, we have to use coordinates in the
containing block's coordinate space, since that's what floats use.
This fixes an issue where text would sometimes overlap floats.
|
|
|
|
We were subtracting the content width of right-floated boxes from their
X position for no reason. Removing this makes floats snuggle up to each
other on the right side. :^)
|
