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

118 lines
3.9 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>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#pragma once
#include <AK/ByteBuffer.h>
#include <AK/HashMap.h>
#include <AK/HashTable.h>
#include <AK/Noncopyable.h>
#include <AK/RefCounted.h>
#include <AK/URL.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/WeakPtr.h>
#include <AK/Weakable.h>
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
#include <LibGfx/Forward.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/Forward.h>
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
#include <LibWeb/Loader/LoadRequest.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
namespace Web {
class ResourceClient;
class Resource : public RefCounted<Resource> {
AK_MAKE_NONCOPYABLE(Resource);
AK_MAKE_NONMOVABLE(Resource);
public:
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
enum class Type {
Generic,
Image,
};
static NonnullRefPtr<Resource> create(Badge<ResourceLoader>, Type, const LoadRequest&);
virtual ~Resource();
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: 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
Type type() const { return m_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
bool is_loaded() const { return m_loaded; }
bool is_failed() const { return m_failed; }
const String& error() const { return m_error; }
bool has_encoded_data() const { return !m_encoded_data.is_null(); }
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
const URL& url() const { return m_request.url(); }
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
const ByteBuffer& encoded_data() const { return m_encoded_data; }
LibWeb: Turn FrameLoader into a ResourceClient We now use the new resource-based loader for the main resource in each Frame. This gives us access to caching and sharing. :^)
2020-06-06 13:38:08 +02:00
const HashMap<String, String, CaseInsensitiveStringTraits>& response_headers() const { return m_response_headers; }
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
void register_client(Badge<ResourceClient>, ResourceClient&);
void unregister_client(Badge<ResourceClient>, ResourceClient&);
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
const String& encoding() const { return m_encoding; }
const String& mime_type() const { return m_mime_type; }
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 for_each_client(Function<void(ResourceClient&)>);
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
ProtocolServer: Stream the downloaded data if possible This patchset makes ProtocolServer stream the downloads to its client (LibProtocol), and as such changes the download API; a possible download lifecycle could be as such: notation = client->server:'>', server->client:'<', pipe activity:'*' ``` > StartDownload(GET, url, headers, {}) < Response(0, fd 8) * {data, 1024b} < HeadersBecameAvailable(0, response_headers, 200) < DownloadProgress(0, 4K, 1024) * {data, 1024b} * {data, 1024b} < DownloadProgress(0, 4K, 2048) * {data, 1024b} < DownloadProgress(0, 4K, 1024) < DownloadFinished(0, true, 4K) ``` Since managing the received file descriptor is a pain, LibProtocol implements `Download::stream_into(OutputStream)`, which can be used to stream the download into any given output stream (be it a file, or memory, or writing stuff with a delay, etc.). Also, as some of the users of this API require all the downloaded data upfront, LibProtocol also implements `set_should_buffer_all_input()`, which causes the download instance to buffer all the data until the download is complete, and to call the `on_buffered_download_finish` hook.
2020-12-26 17:14:12 +03:30
void did_load(Badge<ResourceLoader>, ReadonlyBytes data, const HashMap<String, String, CaseInsensitiveStringTraits>& headers);
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
void did_fail(Badge<ResourceLoader>, const String& error);
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
protected:
explicit Resource(Type, const LoadRequest&);
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
private:
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
LoadRequest m_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
ByteBuffer m_encoded_data;
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
Type m_type { Type::Generic };
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
bool m_loaded { false };
bool m_failed { false };
String m_error;
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
String m_encoding;
String m_mime_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
HashMap<String, String, CaseInsensitiveStringTraits> m_response_headers;
HashTable<ResourceClient*> m_clients;
};
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
class ResourceClient : public Weakable<ResourceClient> {
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
public:
virtual ~ResourceClient();
virtual void resource_did_load() { }
virtual void resource_did_fail() { }
protected:
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
virtual Resource::Type client_type() const { return Resource::Type::Generic; }
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
Resource* resource() { return m_resource; }
const Resource* resource() const { return m_resource; }
void set_resource(Resource*);
private:
RefPtr<Resource> m_resource;
};
}
Reference in a new issue Copy permalink