Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/HTML/TextMetrics.cpp

35 lines
716 B
C++
Raw Normal View History

LibWeb: Implement CanvasRenderingContext2D.measureText This requires an implementation of the "text preparation algorithm" as specified here: html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm However, we're missing a lot of things such as the CanvasTextDrawingStyles interface, so most of the algorithm was not implemented. Additionally, we also are not able to use a LineBox like the algorithm suggests, because our layouting infra is not up to the task yet. The prepare_text function does nothing other than figuring out the width of the given text and return glyphs with offsets at the moment.
2021-12-30 22:15:38 +00:00
/*
* Copyright (c) 2021, sin-ack <sin-ack@protonmail.com>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Remove unecessary dependence on Window from HTML classes These classes only needed Window to get at its realm. Pass a realm directly to construct HTML classes.
2022-09-25 16:38:21 -06:00
#include <LibWeb/Bindings/Intrinsics.h>
LibWeb: Remove Bindings/Forward.h from LibWeb/Forward.h This was resulting in a whole lot of rebuilding whenever a new IDL interface was added. Instead, just directly include the prototype in every C++ file which needs it. While we only really need a forward declaration in each cpp file; including the full prototype header (which itself only includes LibJS/Object.h, which is already transitively brought in by PlatformObject) - it seems like a small price to pay compared to what feels like a full rebuild of LibWeb whenever a new IDL file is added. Given all of these includes are only needed for the ::initialize method, there is probably a smart way of avoiding this problem altogether. I've considered both using some macro trickery or generating these functions somehow instead.
2024-04-27 12:09:58 +12:00
#include <LibWeb/Bindings/TextMetricsPrototype.h>
LibWeb: Make TextMetrics GC-allocated
2022-09-02 23:58:31 +02:00
#include <LibWeb/HTML/TextMetrics.h>
LibWeb: Make factory method of HTML::TextMetrics fallible
2023-02-15 19:12:53 +01:00
#include <LibWeb/WebIDL/ExceptionOr.h>
LibWeb: Implement CanvasRenderingContext2D.measureText This requires an implementation of the "text preparation algorithm" as specified here: html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm However, we're missing a lot of things such as the CanvasTextDrawingStyles interface, so most of the algorithm was not implemented. Additionally, we also are not able to use a LineBox like the algorithm suggests, because our layouting infra is not up to the task yet. The prepare_text function does nothing other than figuring out the width of the given text and return glyphs with offsets at the moment.
2021-12-30 22:15:38 +00:00
namespace Web::HTML {
LibWeb: Put most LibWeb GC objects in type-specific heap blocks With this change, we now have ~1200 CellAllocators across both LibJS and LibWeb in a normal WebContent instance. This gives us a minimum heap size of 4.7 MiB in the scenario where we only have one cell allocated per type. Of course, in practice there will be many more of each type, so the effective overhead is quite a bit smaller than that in practice. I left a few types unconverted to this mechanism because I got tired of doing this. :^)
2023-11-19 19:47:52 +01:00
JS_DEFINE_ALLOCATOR(TextMetrics);
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 13:05:26 +02:00
JS::NonnullGCPtr<TextMetrics> TextMetrics::create(JS::Realm& realm)
LibWeb: Implement CanvasRenderingContext2D.measureText This requires an implementation of the "text preparation algorithm" as specified here: html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm However, we're missing a lot of things such as the CanvasTextDrawingStyles interface, so most of the algorithm was not implemented. Additionally, we also are not able to use a LineBox like the algorithm suggests, because our layouting infra is not up to the task yet. The prepare_text function does nothing other than figuring out the width of the given text and return glyphs with offsets at the moment.
2021-12-30 22:15:38 +00:00
{
LibJS: Make Heap::allocate<T>() infallible Stop worrying about tiny OOMs. Work towards #20449. While going through these, I also changed the function signature in many places where returning ThrowCompletionOr<T> is no longer necessary.
2023-08-13 13:05:26 +02:00
return realm.heap().allocate<TextMetrics>(realm, realm);
LibWeb: Implement CanvasRenderingContext2D.measureText This requires an implementation of the "text preparation algorithm" as specified here: html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm However, we're missing a lot of things such as the CanvasTextDrawingStyles interface, so most of the algorithm was not implemented. Additionally, we also are not able to use a LineBox like the algorithm suggests, because our layouting infra is not up to the task yet. The prepare_text function does nothing other than figuring out the width of the given text and return glyphs with offsets at the moment.
2021-12-30 22:15:38 +00:00
}
LibWeb: Remove unecessary dependence on Window from HTML classes These classes only needed Window to get at its realm. Pass a realm directly to construct HTML classes.
2022-09-25 16:38:21 -06:00
TextMetrics::TextMetrics(JS::Realm& realm)
: PlatformObject(realm)
LibWeb: Make TextMetrics GC-allocated
2022-09-02 23:58:31 +02:00
{
}
TextMetrics::~TextMetrics() = default;
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
void TextMetrics::initialize(JS::Realm& realm)
LibWeb: Move setting of Web object prototypes to initialize() This needs to happen before prototype/constructor intitialization can be made lazy. Otherwise, GC could run during the C++ constructor and try to collect the object currently being created.
2023-01-10 06:28:20 -05:00
{
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
Base::initialize(realm);
LibWeb: Avoid FlyString lookups when setting IDL interface prototypes This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that caches the interface name in a local static FlyString. This means that we only pay for FlyString-from-literal lookup once per browser lifetime instead of every time the interface is instantiated.
2024-03-16 13:13:08 +01:00
WEB_SET_PROTOTYPE_FOR_INTERFACE(TextMetrics);
LibWeb: Move setting of Web object prototypes to initialize() This needs to happen before prototype/constructor intitialization can be made lazy. Otherwise, GC could run during the C++ constructor and try to collect the object currently being created.
2023-01-10 06:28:20 -05:00
}
LibWeb: Implement CanvasRenderingContext2D.measureText This requires an implementation of the "text preparation algorithm" as specified here: html.spec.whatwg.org/multipage/canvas.html#text-preparation-algorithm However, we're missing a lot of things such as the CanvasTextDrawingStyles interface, so most of the algorithm was not implemented. Additionally, we also are not able to use a LineBox like the algorithm suggests, because our layouting infra is not up to the task yet. The prepare_text function does nothing other than figuring out the width of the given text and return glyphs with offsets at the moment.
2021-12-30 22:15:38 +00:00
}
Reference in a new issue Copy permalink