Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 21:30:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Loader/Resource.cpp

161 lines
5.1 KiB
C++
Raw Normal View History

LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
*/
Everywhere: Replace a bundle of dbg with dbgln. These changes are arbitrarily divided into multiple commits to make it easier to find potentially introduced bugs with git bisect.
2021-01-17 18:17:00 +01:00
#include <AK/Debug.h>
LibWeb: Protect ourselves during ResourceClient iteration Notifying a Resource's clients may lead to arbitrary JS execution, so we can't rely on the ResourceClient pointers remaining valid. Use WeakPtr to avoid this problem.
2020-06-01 22:09:38 +02:00
#include <AK/Function.h>
LibCore+LibWeb: Move guess-mimetype-based-on-filename logic to LibCore This could be useful in more places.
2020-07-27 19:49:43 +02:00
#include <LibCore/MimeData.h>
LibWeb: Move HTML object model stuff into LibWeb/HTML/ Take a hint from SVG and more all the HTML classes into HTML instead of mixing them with the DOM classes.
2020-07-26 15:08:16 +02:00
#include <LibWeb/HTML/HTMLImageElement.h>
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
#include <LibWeb/Loader/Resource.h>
namespace Web {
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
NonnullRefPtr<Resource> Resource::create(Badge<ResourceLoader>, Type type, const LoadRequest& request)
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
{
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
if (type == Type::Image)
AK: Rename adopt() to adopt_ref() This makes it more symmetrical with adopt_own() (which is used to create a NonnullOwnPtr from the result of a naked new.)
2021-04-23 16:46:57 +02:00
return adopt_ref(*new ImageResource(request));
return adopt_ref(*new Resource(type, request));
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
}
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
Resource::Resource(Type type, const LoadRequest& request)
LibWeb: Add a naive Resource cache This patch introduces a caching mechanism in ResourceLoader. It's keyed on a LoadRequest object which is what you provide to load_resource() when you want to load a resource. We currently never prune the cache, so resources will stay in there forever. This is obviously not gonna stay that way, but we're just getting started here. :^) This should drastically reduce the number of requests when loading some sites (like Twitter) that reuse the same images over and over.
2020-06-01 21:58:29 +02:00
: m_request(request)
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
, m_type(type)
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
{
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
Resource::~Resource() = default;
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Protect ourselves during ResourceClient iteration Notifying a Resource's clients may lead to arbitrary JS execution, so we can't rely on the ResourceClient pointers remaining valid. Use WeakPtr to avoid this problem.
2020-06-01 22:09:38 +02:00
void Resource::for_each_client(Function<void(ResourceClient&)> callback)
{
Vector<WeakPtr<ResourceClient>, 16> clients_copy;
clients_copy.ensure_capacity(m_clients.size());
for (auto* client : m_clients)
clients_copy.append(client->make_weak_ptr());
for (auto client : clients_copy) {
if (client)
callback(*client);
}
}
LibWeb: Use Optional<String> for encoding_from_content_type This patch changes the encoding_from_content_type function to only return an encoding if it actually finds one, and leave it up to the caller to decided on a default to use. It also modifies the caller to expect an Optional<String> (instead of relying on the null state of the String class) as a return value and separates the encoding and MIME type determination. This will be built upon in a further commit.
2021-05-12 10:07:17 +02:00
static Optional<String> encoding_from_content_type(const String& content_type)
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
{
AK+Everywhere: Consolidate String::index_of() and String::find() We had two functions for doing mostly the same thing. Combine both of them into String::find() and use that everywhere. Also add some tests to cover basic behavior.
2021-05-24 11:50:46 +02:00
auto offset = content_type.find("charset="sv);
LibWeb: Tolerate quoted HTTP Content-Type encodings
2020-06-25 22:23:47 +02:00
if (offset.has_value()) {
auto encoding = content_type.substring(offset.value() + 8, content_type.length() - offset.value() - 8).to_lowercase();
if (encoding.length() >= 2 && encoding.starts_with('"') && encoding.ends_with('"'))
return encoding.substring(1, encoding.length() - 2);
if (encoding.length() >= 2 && encoding.starts_with('\'') && encoding.ends_with('\''))
return encoding.substring(1, encoding.length() - 2);
return encoding;
}
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
LibWeb: Use Optional<String> for encoding_from_content_type This patch changes the encoding_from_content_type function to only return an encoding if it actually finds one, and leave it up to the caller to decided on a default to use. It also modifies the caller to expect an Optional<String> (instead of relying on the null state of the String class) as a return value and separates the encoding and MIME type determination. This will be built upon in a further commit.
2021-05-12 10:07:17 +02:00
return {};
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
}
LibWeb: Mark compilation-unit-only functions as static This enables a nice warning in case a function becomes dead code. Also, in the case of {Event,Node}WrapperFactory.cpp, the corresponding header was forgotten. This would cause an issue later when we enable -Wmissing-declarations. Is my clang-format misconfigured? Why is the diff for NodeWrapperFactory.cpp so large?
2020-08-11 00:07:16 +02:00
static String mime_type_from_content_type(const String& content_type)
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
{
AK+Everywhere: Consolidate String::index_of() and String::find() We had two functions for doing mostly the same thing. Combine both of them into String::find() and use that everywhere. Also add some tests to cover basic behavior.
2021-05-24 11:50:46 +02:00
auto offset = content_type.find(';');
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
if (offset.has_value())
return content_type.substring(0, offset.value()).to_lowercase();
return content_type;
}
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
void Resource::did_load(Badge<ResourceLoader>, ReadonlyBytes data, const HashMap<String, String, CaseInsensitiveStringTraits>& headers, Optional<u32> status_code)
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!m_loaded);
Everywhere: Make ByteBuffer::{create_*,copy}() OOM-safe
2021-09-06 03:29:52 +04:30
// FIXME: Handle OOM failure.
Everywhere: Convert ByteBuffer factory methods from Optional -> ErrorOr Apologies for the enormous commit, but I don't see a way to split this up nicely. In the vast majority of cases it's a simple change. A few extra places can use TRY instead of manual error checking though. :^)
2022-01-20 17:47:39 +00:00
m_encoded_data = ByteBuffer::copy(data).release_value_but_fixme_should_propagate_errors();
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_response_headers = headers;
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
m_status_code = move(status_code);
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_loaded = true;
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
auto content_type = headers.get("Content-Type");
LibWeb: Use Optional<String> for encoding_from_content_type This patch changes the encoding_from_content_type function to only return an encoding if it actually finds one, and leave it up to the caller to decided on a default to use. It also modifies the caller to expect an Optional<String> (instead of relying on the null state of the String class) as a return value and separates the encoding and MIME type determination. This will be built upon in a further commit.
2021-05-12 10:07:17 +02:00
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
if (content_type.has_value()) {
Everywhere: Turn #if *_DEBUG into dbgln_if/if constexpr
2021-05-01 21:10:08 +02:00
dbgln_if(RESOURCE_DEBUG, "Content-Type header: '{}'", content_type.value());
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
m_mime_type = mime_type_from_content_type(content_type.value());
LibWeb: Add a workaround to assign a proper mime type to QOI images
2021-12-21 01:27:38 +01:00
// FIXME: "The Quite OK Image Format" doesn't have an official mime type yet,
// and servers like nginx will send a generic octet-stream mime type instead.
// Let's use image/x-qoi for now, which is also what our Core::MimeData uses & would guess.
if (m_mime_type == "application/octet-stream" && url().path().ends_with(".qoi"))
m_mime_type = "image/x-qoi";
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
} else if (url().protocol() == "data" && !url().data_mime_type().is_empty()) {
Everywhere: Replace dbgln<flag>(...) with dbgln_if(flag, ...) Replacement made by `find Kernel Userland -name '*.h' -o -name '*.cpp' | sed -i -Ee 's/dbgln\b<(\w+)>\(/dbgln_if(\1, /g'`
2021-02-07 15:33:24 +03:30
dbgln_if(RESOURCE_DEBUG, "This is a data URL with mime-type _{}_", url().data_mime_type());
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
m_mime_type = url().data_mime_type();
} else {
LibWeb: Support X-Content-Type-Options to opt out of MIME type sniffing
2021-05-19 13:37:36 +00:00
auto content_type_options = headers.get("X-Content-Type-Options");
if (content_type_options.value_or("").equals_ignoring_case("nosniff")) {
m_mime_type = "text/plain";
} else {
m_mime_type = Core::guess_mime_type_based_on_filename(url().path());
}
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
}
LibWeb: Change Resource's m_encoding to Optional<String> This modifies the Resource class to use Optional<String> for the encoding. If the encoding is unknown, the Optional will not have a value (instead of using the null state of the String class). It also implements a has_encoding() instance method and modifies the callers of Resource::encoding() to use the new API.
2021-05-12 10:21:00 +02:00
m_encoding = {};
LibWeb: Use Optional<String> for encoding_from_content_type This patch changes the encoding_from_content_type function to only return an encoding if it actually finds one, and leave it up to the caller to decided on a default to use. It also modifies the caller to expect an Optional<String> (instead of relying on the null state of the String class) as a return value and separates the encoding and MIME type determination. This will be built upon in a further commit.
2021-05-12 10:07:17 +02:00
if (content_type.has_value()) {
auto encoding = encoding_from_content_type(content_type.value());
if (encoding.has_value()) {
dbgln_if(RESOURCE_DEBUG, "Set encoding '{}' from Content-Type", encoding.has_value());
m_encoding = encoding.value();
}
}
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
for_each_client([](auto& client) {
client.resource_did_load();
});
}
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
void Resource::did_fail(Badge<ResourceLoader>, const String& error, Optional<u32> status_code)
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
{
m_error = error;
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
m_status_code = move(status_code);
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_failed = true;
for_each_client([](auto& client) {
client.resource_did_fail();
});
}
void Resource::register_client(Badge<ResourceClient>, ResourceClient& client)
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(!m_clients.contains(&client));
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_clients.set(&client);
}
void Resource::unregister_client(Badge<ResourceClient>, ResourceClient& client)
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(m_clients.contains(&client));
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_clients.remove(&client);
}
void ResourceClient::set_resource(Resource* resource)
{
if (m_resource)
m_resource->unregister_client({}, *this);
m_resource = resource;
if (m_resource) {
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(resource->type() == client_type());
LibWeb: Fix mismatching Resource subclass types This was a confusing bug: ImageStyleValue loaded its image resource as a Generic resource, while HTMLImageElement loaded as Image. This patch fixes the issue and adds an assertion to verify that we only share resources that have the same C++ client class type.
2020-06-05 23:32:23 +02:00
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
m_resource->register_client({}, *this);
// Make sure that reused resources also have their load callback fired.
if (resource->is_loaded())
resource_did_load();
// Make sure that reused resources also have their fail callback fired.
if (resource->is_failed())
resource_did_fail();
}
}
ResourceClient::~ResourceClient()
{
if (m_resource)
m_resource->unregister_client({}, *this);
}
}
Reference in a new issue Copy permalink