@nativescript/canvas 2.0.0-alpha.3 → 2.0.0-alpha.5

package/platforms/ios/src/cpp/webgl/WebGLRenderingContextBase.h

@@ -15,6 +15,7 @@
 #include "Helpers.h"
 #include "RafImpl.h"
 #include "OnRafCallback.h"
+#include "gl.h"
 
 enum class WebGLRenderingVersion : uint8_t {
     V1,
@@ -49,7 +50,31 @@ public:
     RafImpl *GetRaf();
 
     WebGLRenderingVersion GetVersion() const;
-
+    
+    int GetDisplayFramebuffer(){
+        return displayFramebuffer_;
+    }
+
+    int GetDisplayRenderbuffer(){
+        return displayRenderbuffer_;
+    }
+    
+    void StartRaf();
+    void StopRaf();
+    
+    void UpdateBindings(){
+        auto displayFramebuffer = canvas_native_webgl_get_parameter(GL_FRAMEBUFFER_BINDING, *state_);
+        
+        auto displayRenderbuffer = canvas_native_webgl_get_parameter(GL_RENDERER, *state_);
+        
+        if(!canvas_native_webgl_result_get_is_none(*displayFramebuffer)){
+            displayFramebuffer_ = canvas_native_webgl_result_get_i32(*displayFramebuffer);
+        }
+        
+        if(!canvas_native_webgl_result_get_is_none(*displayRenderbuffer)){
+            displayRenderbuffer_ = canvas_native_webgl_result_get_i32(*displayRenderbuffer);
+        }
+    }
 
 private:
     rust::Box<WebGLState> state_;
@@ -59,5 +84,7 @@ private:
     int invalidateState_ = static_cast<int>(InvalidateState::NONE);
 
     std::shared_ptr<RafImpl> raf_;
+    int displayFramebuffer_;
+    int displayRenderbuffer_;
 };
 

package/platforms/ios/src/cpp/webgl/WebGLRenderingContextBase.mm

@@ -6,29 +6,50 @@
 
 WebGLRenderingContextBase::WebGLRenderingContextBase(rust::Box<WebGLState> state,
                                                      WebGLRenderingVersion version)
-        : state_(std::move(state)), version_(version) {
-
-
+: state_(std::move(state)), version_(version) {
+    
+    
     auto ctx_ptr = reinterpret_cast<intptr_t>(reinterpret_cast<intptr_t *>(this));
     auto raf_callback = new OnRafCallback(
-            ctx_ptr,
-            version == WebGLRenderingVersion::V2 ? 2 : 1);
+                                          ctx_ptr,
+                                          version == WebGLRenderingVersion::V2 ? 2 : 1);
     auto raf_callback_ptr = reinterpret_cast<intptr_t>(reinterpret_cast<intptr_t *>(raf_callback));
     auto raf = canvas_native_raf_create(
-            raf_callback_ptr);
+                                        raf_callback_ptr);
     this->SetRaf(
-            std::make_shared<RafImpl>(
-                    raf_callback,
-                    raf_callback_ptr,
-                    std::move(
-                            raf)));
-
+                 std::make_shared<RafImpl>(
+                                           raf_callback,
+                                           raf_callback_ptr,
+                                           std::move(
+                                                     raf)));
+    
     auto _raf = this->GetRaf();
-
+    
     if (_raf != nullptr) {
         canvas_native_raf_start(_raf->GetRaf());
     }
+    
+    UpdateBindings();
+}
 
+
+void WebGLRenderingContextBase::StartRaf() {
+    auto raf = this->GetRaf();
+    if (raf != nullptr) {
+        if (!canvas_native_raf_get_started(raf->GetRaf())) {
+            canvas_native_raf_start(raf->GetRaf());
+        }
+    }
+}
+
+
+void WebGLRenderingContextBase::StopRaf() {
+    auto raf = this->GetRaf();
+    if (raf != nullptr) {
+        if (canvas_native_raf_get_started(raf->GetRaf())) {
+            canvas_native_raf_stop(raf->GetRaf());
+        }
+    }
 }
 
 void WebGLRenderingContextBase::UpdateInvalidateState() {
@@ -92,6 +113,6 @@ WebGLRenderingContextBase::~WebGLRenderingContextBase() {
     auto _raf = this->GetRaf();
     if (_raf != nullptr) {
         canvas_native_raf_start(
-                _raf->GetRaf());
+                                _raf->GetRaf());
     }
 }

package/platforms/ios/src/cpp/webgl/extensions/OES_fbo_render_mipmap.h

@@ -0,0 +1,30 @@
+//
+// Created by Osei Fortune on 02/05/2022.
+//
+
+#pragma once
+
+#include "rust/cxx.h"
+#include "NativeScript/JSIRuntime.h"
+
+using namespace facebook;
+
+class JSI_EXPORT OES_fbo_render_mipmapImpl : public jsi::HostObject {
+public:
+    std::vector<jsi::PropNameID> getPropertyNames(jsi::Runtime &rt) override {
+        std::vector<jsi::PropNameID> ret;
+        ret.emplace_back(
+                jsi::PropNameID::forUtf8(rt, std::string("ext_name")));
+        return ret;
+    }
+
+    jsi::Value get(jsi::Runtime &runtime, const jsi::PropNameID &name) override {
+        auto methodName = name.utf8(runtime);
+
+        if (methodName == "ext_name") {
+            return jsi::String::createFromAscii(runtime, "OES_fbo_render_mipmap");
+        }
+
+        return jsi::Value::undefined();
+    }
+};

package/platforms/ios/src/cpp/webgl2/WebGL2RenderingContext.mm

@@ -20,7 +20,7 @@ std::vector<jsi::PropNameID> WebGL2RenderingContext::getPropertyNames(jsi::Runti
     std::vector<jsi::PropNameID> ret;
 
     // gl2 + gl1 props
-    ret.reserve(351 + 434);
+    ret.reserve(353 + 434);
 
     // 351
     ret.push_back(jsi::PropNameID::forAscii(rt, "beginQuery"));
@@ -499,6 +499,8 @@ std::vector<jsi::PropNameID> WebGL2RenderingContext::getPropertyNames(jsi::Runti
     /* GL 1 */
 
     ret.push_back(jsi::PropNameID::forUtf8(rt, "__resized"));
+    ret.push_back(jsi::PropNameID::forUtf8(rt, "__startRaf"));
+    ret.push_back(jsi::PropNameID::forUtf8(rt, "__stopRaf"));
     ret.push_back(jsi::PropNameID::forUtf8(rt, std::string("activeTexture")));
     ret.push_back(jsi::PropNameID::forUtf8(rt, std::string("attachShader")));
     ret.push_back(jsi::PropNameID::forUtf8(rt, std::string("bindAttribLocation")));

package/pods/Headers/include/APIDesign.md

@@ -0,0 +1,72 @@
+# The V8 public C++ API
+
+# Overview
+
+The V8 public C++ API aims to support four use cases:
+
+1. Enable applications that embed V8 (called the embedder) to configure and run
+   one or more instances of V8.
+2. Expose ECMAScript-like capabilities to the embedder.
+3. Enable the embedder to interact with ECMAScript by exposing API objects.
+4. Provide access to the V8 debugger (inspector).
+
+# Configuring and running an instance of V8
+
+V8 requires access to certain OS-level primitives such as the ability to
+schedule work on threads, or allocate memory.
+
+The embedder can define how to access those primitives via the v8::Platform
+interface. While V8 bundles a basic implementation, embedders are highly
+encouraged to implement v8::Platform themselves.
+
+Currently, the v8::ArrayBuffer::Allocator is passed to the v8::Isolate factory
+method, however, conceptually it should also be part of the v8::Platform since
+all instances of V8 should share one allocator.
+
+Once the v8::Platform is configured, an v8::Isolate can be created. All
+further interactions with V8 should explicitly reference the v8::Isolate they
+refer to. All API methods should eventually take an v8::Isolate parameter.
+
+When a given instance of V8 is no longer needed, it can be destroyed by
+disposing the respective v8::Isolate. If the embedder wishes to free all memory
+associated with the v8::Isolate, it has to first clear all global handles
+associated with that v8::Isolate.
+
+# ECMAScript-like capabilities
+
+In general, the C++ API shouldn't enable capabilities that aren't available to
+scripts running in V8. Experience has shown that it's not possible to maintain
+such API methods in the long term. However, capabilities also available to
+scripts, i.e., ones that are defined in the ECMAScript standard are there to
+stay, and we can safely expose them to embedders.
+
+The C++ API should also be pleasant to use, and not require learning new
+paradigms. Similarly to how the API exposed to scripts aims to provide good
+ergonomics, we should aim to provide a reasonable developer experience for this
+API surface.
+
+ECMAScript makes heavy use of exceptions, however, V8's C++ code doesn't use
+C++ exceptions. Therefore, all API methods that can throw exceptions should
+indicate so by returning a v8::Maybe<> or v8::MaybeLocal<> result,
+and by taking a v8::Local<v8::Context> parameter that indicates in which
+context a possible exception should be thrown.
+
+# API objects
+
+V8 allows embedders to define special objects that expose additional
+capabilities and APIs to scripts. The most prominent example is exposing the
+HTML DOM in Blink. Other examples are e.g. node.js. It is less clear what kind
+of capabilities we want to expose via this API surface. As a rule of thumb, we
+want to expose operations as defined in the WebIDL and HTML spec: we
+assume that those requirements are somewhat stable, and that they are a
+superset of the requirements of other embedders including node.js.
+
+Ideally, the API surfaces defined in those specs hook into the ECMAScript spec
+which in turn guarantees long-term stability of the API.
+
+# The V8 inspector
+
+All debugging capabilities of V8 should be exposed via the inspector protocol.
+The exception to this are profiling features exposed via v8-profiler.h.
+Changes to the inspector protocol need to ensure backwards compatibility and
+commitment to maintain.

package/pods/Headers/include/DEPS

@@ -0,0 +1,10 @@
+include_rules = [
+  # v8-inspector-protocol.h depends on generated files under include/inspector.
+  "+inspector",
+  "+cppgc/common.h",
+  # Used by v8-cppgc.h to bridge to cppgc.
+  "+cppgc/custom-space.h",
+  "+cppgc/heap-statistics.h",
+  "+cppgc/internal/write-barrier.h",
+  "+cppgc/visitor.h",
+]

package/pods/Headers/include/DIR_METADATA

@@ -0,0 +1,11 @@
+# Metadata information for this directory.
+#
+# For more information on DIR_METADATA files, see:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/README.md
+#
+# For the schema of this file, see Metadata message:
+#   https://source.chromium.org/chromium/infra/infra/+/master:go/src/infra/tools/dirmd/proto/dir_metadata.proto
+
+monorail {
+  component: "Blink>JavaScript>API"
+}

package/pods/Headers/include/OWNERS

@@ -0,0 +1,23 @@
+adamk@chromium.org
+cbruni@chromium.org
+leszeks@chromium.org
+mlippautz@chromium.org
+verwaest@chromium.org
+yangguo@chromium.org
+
+per-file *DEPS=file:../COMMON_OWNERS
+per-file v8-internal.h=file:../COMMON_OWNERS
+
+per-file v8-debug.h=file:../src/debug/OWNERS
+
+per-file js_protocol.pdl=file:../src/inspector/OWNERS
+per-file v8-inspector*=file:../src/inspector/OWNERS
+per-file v8-inspector*=file:../src/inspector/OWNERS
+
+# Needed by the auto_tag builder
+per-file v8-version.h=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com
+
+# For branch updates:
+per-file v8-version.h=file:../INFRA_OWNERS
+per-file v8-version.h=hablich@chromium.org
+per-file v8-version.h=vahl@chromium.org

package/pods/Headers/include/cppgc/DEPS

@@ -0,0 +1,8 @@
+include_rules = [
+  "-include",
+  "+v8config.h",
+  "+v8-platform.h",
+  "+cppgc",
+  "-src",
+  "+libplatform/libplatform.h",
+]

package/pods/Headers/include/cppgc/OWNERS

@@ -0,0 +1,2 @@
+bikineev@chromium.org
+omerkatz@chromium.org

package/pods/Headers/include/cppgc/README.md

@@ -0,0 +1,133 @@
+# Oilpan: C++ Garbage Collection
+
+Oilpan is an open-source garbage collection library for C++ that can be used stand-alone or in collaboration with V8's JavaScript garbage collector.
+Oilpan implements mark-and-sweep garbage collection (GC) with limited compaction (for a subset of objects).
+
+**Key properties**
+
+- Trace-based garbage collection;
+- Incremental and concurrent marking;
+- Incremental and concurrent sweeping;
+- Precise on-heap memory layout;
+- Conservative on-stack memory layout;
+- Allows for collection with and without considering stack;
+- Non-incremental and non-concurrent compaction for selected spaces;
+
+See the [Hello World](https://chromium.googlesource.com/v8/v8/+/main/samples/cppgc/hello-world.cc) example on how to get started using Oilpan to manage C++ code.
+
+Oilpan follows V8's project organization, see e.g. on how we accept [contributions](https://v8.dev/docs/contribute) and [provide a stable API](https://v8.dev/docs/api).
+
+## Threading model
+
+Oilpan features thread-local garbage collection and assumes heaps are not shared among threads.
+In other words, objects are accessed and ultimately reclaimed by the garbage collector on the same thread that allocates them.
+This allows Oilpan to run garbage collection in parallel with mutators running in other threads.
+
+References to objects belonging to another thread's heap are modeled using cross-thread roots.
+This is even true for on-heap to on-heap references.
+
+## Heap partitioning
+
+Oilpan's heaps are partitioned into spaces.
+The space for an object is chosen depending on a number of criteria, e.g.:
+
+- Objects over 64KiB are allocated in a large object space
+- Objects can be assigned to a dedicated custom space.
+  Custom spaces can also be marked as compactable.
+- Other objects are allocated in one of the normal page spaces bucketed depending on their size.
+
+## Precise and conservative garbage collection
+
+Oilpan supports two kinds of GCs:
+
+1. **Conservative GC.**
+A GC is called conservative when it is executed while the regular native stack is not empty.
+In this case, the native stack might contain references to objects in Oilpan's heap, which should be kept alive.
+The GC scans the native stack and treats the pointers discovered via the native stack as part of the root set.
+This kind of GC is considered imprecise because values on stack other than references may accidentally appear as references to on-heap object, which means these objects will be kept alive despite being in practice unreachable from the application as an actual reference.
+
+2. **Precise GC.**
+A precise GC is triggered at the end of an event loop, which is controlled by an embedder via a platform.
+At this point, it is guaranteed that there are no on-stack references pointing to Oilpan's heap.
+This means there is no risk of confusing other value types with references.
+Oilpan has precise knowledge of on-heap object layouts, and so it knows exactly where pointers lie in memory.
+Oilpan can just start marking from the regular root set and collect all garbage precisely.
+
+## Atomic, incremental and concurrent garbage collection
+
+Oilpan has three modes of operation:
+
+1. **Atomic GC.**
+The entire GC cycle, including all its phases (e.g. see [Marking](#Marking-phase) and [Sweeping](#Sweeping-phase)), are executed back to back in a single pause.
+This mode of operation is also known as Stop-The-World (STW) garbage collection.
+It results in the most jank (due to a single long pause), but is overall the most efficient (e.g. no need for write barriers).
+
+2. **Incremental GC.**
+Garbage collection work is split up into multiple steps which are interleaved with the mutator, i.e. user code chunked into tasks.
+Each step is a small chunk of work that is executed either as dedicated tasks between mutator tasks or, as needed, during mutator tasks.
+Using incremental GC introduces the need for write barriers that record changes to the object graph so that a consistent state is observed and no objects are accidentally considered dead and reclaimed.
+The incremental steps are followed by a smaller atomic pause to finalize garbage collection.
+The smaller pause times, due to smaller chunks of work, helps with reducing jank.
+
+3. **Concurrent GC.**
+This is the most common type of GC.
+It builds on top of incremental GC and offloads much of the garbage collection work away from the mutator thread and on to background threads.
+Using concurrent GC allows the mutator thread to spend less time on GC and more on the actual mutator.
+
+## Marking phase
+
+The marking phase consists of the following steps:
+
+1. Mark all objects in the root set.
+
+2. Mark all objects transitively reachable from the root set by calling `Trace()` methods defined on each object.
+
+3. Clear out all weak handles to unreachable objects and run weak callbacks.
+
+The marking phase can be executed atomically in a stop-the-world manner, in which all 3 steps are executed one after the other.
+
+Alternatively, it can also be executed incrementally/concurrently.
+With incremental/concurrent marking, step 1 is executed in a short pause after which the mutator regains control.
+Step 2 is repeatedly executed in an interleaved manner with the mutator.
+When the GC is ready to finalize, i.e. step 2 is (almost) finished, another short pause is triggered in which step 2 is finished and step 3 is performed.
+
+To prevent a user-after-free (UAF) issues it is required for Oilpan to know about all edges in the object graph.
+This means that all pointers except on-stack pointers must be wrapped with Oilpan's handles (i.e., Persistent<>, Member<>, WeakMember<>).
+Raw pointers to on-heap objects create an edge that Oilpan cannot observe and cause UAF issues
+Thus, raw pointers shall not be used to reference on-heap objects (except for raw pointers on native stacks).
+
+## Sweeping phase
+
+The sweeping phase consists of the following steps:
+
+1. Invoke pre-finalizers.
+At this point, no destructors have been invoked and no memory has been reclaimed.
+Pre-finalizers are allowed to access any other on-heap objects, even those that may get destructed.
+
+2. Sweeping invokes destructors of the dead (unreachable) objects and reclaims memory to be reused by future allocations.
+
+Assumptions should not be made about the order and the timing of their execution.
+There is no guarantee on the order in which the destructors are invoked.
+That's why destructors must not access any other on-heap objects (which might have already been destructed).
+If some destructor unavoidably needs to access other on-heap objects, it will have to be converted to a pre-finalizer.
+The pre-finalizer is allowed to access other on-heap objects.
+
+The mutator is resumed before all destructors have ran.
+For example, imagine a case where X is a client of Y, and Y holds a list of clients.
+If the code relies on X's destructor removing X from the list, there is a risk that Y iterates the list and calls some method of X which may touch other on-heap objects.
+This causes a use-after-free.
+Care must be taken to make sure that X is explicitly removed from the list before the mutator resumes its execution in a way that doesn't rely on X's destructor (e.g. a pre-finalizer).
+
+Similar to marking, sweeping can be executed in either an atomic stop-the-world manner or incrementally/concurrently.
+With incremental/concurrent sweeping, step 2 is interleaved with mutator.
+Incremental/concurrent sweeping can be atomically finalized in case it is needed to trigger another GC cycle.
+Even with concurrent sweeping, destructors are guaranteed to run on the thread the object has been allocated on to preserve C++ semantics.
+
+Notes:
+
+* Weak processing runs only when the holder object of the WeakMember outlives the pointed object.
+If the holder object and the pointed object die at the same time, weak processing doesn't run.
+It is wrong to write code assuming that the weak processing always runs.
+
+* Pre-finalizers are heavy because the thread needs to scan all pre-finalizers at each sweeping phase to determine which pre-finalizers should be invoked (the thread needs to invoke pre-finalizers of dead objects).
+Adding pre-finalizers to frequently created objects should be avoided.