dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Userland/Libraries/LibJS/Runtime/Uint8ClampedArray.cpp

66 lines
1.8 KiB
C++
Raw Normal View History

LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03: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 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
*/
#include <AK/Function.h>
#include <LibJS/Runtime/Error.h>
#include <LibJS/Runtime/GlobalObject.h>
#include <LibJS/Runtime/Uint8ClampedArray.h>
namespace JS {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 01:33:37 -03:00
Uint8ClampedArray* Uint8ClampedArray::create(GlobalObject& global_object, u32 length)
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
{
LibJS: Remove a bunch of unnecessary uses of Cell::interpreter() We'll want to get rid of all uses of this, to free up the engine from the old assumption that there's always an Interpreter available.
2020-09-27 15:07:25 -03:00
return global_object.heap().allocate<Uint8ClampedArray>(global_object, length, *global_object.array_prototype());
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 01:33:37 -03:00
Uint8ClampedArray::Uint8ClampedArray(u32 length, Object& prototype)
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 12:21:53 -03:00
: Object(prototype)
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
, m_length(length)
{
LibJS: Cache commonly used FlyStrings in the VM Roughly 7% of test-js runtime was spent creating FlyStrings from string literals. This patch frontloads that work and caches all the commonly used names in LibJS on a CommonPropertyNames struct that hangs off VM.
2020-10-13 18:49:19 -03:00
auto& vm = this->vm();
AK: Simplify constructors and conversions from nullptr_t Problem: - Many constructors are defined as `{}` rather than using the ` = default` compiler-provided constructor. - Some types provide an implicit conversion operator from `nullptr_t` instead of requiring the caller to default construct. This violates the C++ Core Guidelines suggestion to declare single-argument constructors explicit (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c46-by-default-declare-single-argument-constructors-explicit). Solution: - Change default constructors to use the compiler-provided default constructor. - Remove implicit conversion operators from `nullptr_t` and change usage to enforce type consistency without conversion.
2021-01-10 20:29:28 -03:00
define_native_property(vm.names.length, length_getter, {});
LibJS: Zero out memory in newly allocated Uint8ClampedArray objects
2020-12-01 13:06:48 -03:00
m_data = (u8*)calloc(m_length, 1);
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
}
Uint8ClampedArray::~Uint8ClampedArray()
{
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 16:42:32 -03:00
VERIFY(m_data);
LibJS: Zero out memory in newly allocated Uint8ClampedArray objects
2020-12-01 13:06:48 -03:00
free(m_data);
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
m_data = nullptr;
}
LibJS: Pass GlobalObject& to native functions and property accessors More work towards supporting multiple global objects. Native C++ code now get a GlobalObject& and don't have to ask the Interpreter for it. I've added macros for declaring and defining native callbacks since this was pretty tedious and this makes it easier next time we want to change any of these signatures.
2020-06-20 08:55:34 -03:00
JS_DEFINE_NATIVE_GETTER(Uint8ClampedArray::length_getter)
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
{
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 13:36:49 -03:00
auto* this_object = vm.this_value(global_object).to_object(global_object);
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
if (!this_object)
return {};
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 07:52:32 -03:00
if (StringView(this_object->class_name()) != "Uint8ClampedArray") {
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 13:36:49 -03:00
vm.throw_exception<TypeError>(global_object, ErrorType::NotA, "Uint8ClampedArray");
LibJS: Make Interpreter::throw_exception() a void function The motivation for this change is twofold: - Returning a JS::Value is misleading as one would expect it to carry some meaningful information, like maybe the error object that's being created, but in fact it is always empty. Supposedly to serve as a shortcut for the common case of "throw and return empty value", but that's just leading us to my second point. - Inconsistent usage / coding style: as of this commit there are 114 uses of throw_exception() discarding its return value and 55 uses directly returning the call result (in LibJS, not counting LibWeb); with the first style often having a more explicit empty value (or nullptr in some cases) return anyway. One more line to always make the return value obvious is should be worth it. So now it's basically always these steps, which is already being used in the majority of cases (as outlined above): - Throw an exception. This mutates interpreter state by updating m_exception and unwinding, but doesn't return anything. - Let the caller explicitly return an empty value, nullptr or anything else itself.
2020-08-25 07:52:32 -03:00
return {};
}
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
return Value(static_cast<const Uint8ClampedArray*>(this_object)->length());
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 01:33:37 -03:00
bool Uint8ClampedArray::put_by_index(u32 property_index, Value value)
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
{
LibJS: Have Uint8ClampedArray delegate OOB accesses to JS::Object Uint8ClampedArray itself only cares about legitimate in-bounds accesses since that's what where the specialization happens.
2020-12-01 13:10:57 -03:00
if (property_index >= m_length)
return Base::put_by_index(property_index, value);
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 13:36:49 -03:00
auto number = value.to_i32(global_object());
LibJS: Use VM::exception() instead of Interpreter::exception() a bunch There's a lot more of these things to fix. We'll also want to move from passing Interpreter& around to VM& instead wherever that is enough.
2020-09-21 11:46:45 -03:00
if (vm().exception())
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-17 20:28:00 -03:00
return {};
m_data[property_index] = clamp(number, 0, 255);
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 16:01:54 -03:00
return true;
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-27 01:33:37 -03:00
Value Uint8ClampedArray::get_by_index(u32 property_index) const
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
{
LibJS: Have Uint8ClampedArray delegate OOB accesses to JS::Object Uint8ClampedArray itself only cares about legitimate in-bounds accesses since that's what where the specialization happens.
2020-12-01 13:10:57 -03:00
if (property_index >= m_length)
return Base::get_by_index(property_index);
LibJS: Add Uint8ClampedArray :^) This is a special kind of byte array that clamps its values to 0...255 It will be used for HTML ImageData objects. I made Object::put_by_index() and get_by_index() virtual for this. We'll probably need to make non-numeric property name lookups virtual as well, but this solves my current problem well enough.
2020-04-21 18:46:51 -03:00
return Value((i32)m_data[property_index]);
}
}
Reference in a new issue Copy permalink