Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renderer v1.0.0 #325

Merged
merged 104 commits into from
Jul 15, 2024
Merged

Renderer v1.0.0 #325

merged 104 commits into from
Jul 15, 2024

Conversation

wouterlucas and others added 30 commits May 23, 2024 09:10
- Remove CoreExtension concept
Hopefully...
ThreadX is a feature implemented to support offscreen canvas
multithreading, however browser support for ThreadX will not come soon
to our space (TV / STB market) and the current implementation has some
negative side effects.

With the introduction of Drivers there is a lot of double housekeeping,
maintaining two tree's of nodes, the `DriverNode` and `CoreNode`. This
causes additional processing overhead (mainly extra function invocations
and emitters) and an additional list of nodes stored in memory.

In the future we should ensure all ThreadX specifics are retained in the
ThreadX module, likely by providing a RendererMain replacement from the
ThreadX project and proxy the CoreNode respectively as we communicate
over threads. And keep the specifics to ThreadX to where they belong.

Early test results:
current master: 20k nodes create 2867ms @ 65 MB HEAP:

![image_2024_05_27T19_51_20_477Z](https://github.com/lightning-js/renderer/assets/1534440/924d80c6-9f92-49f4-b5fe-99489ae2651d)
![image_2024_05_27T19_52_05_633Z](https://github.com/lightning-js/renderer/assets/1534440/b86a4f66-2170-4a01-95b4-351f4eef3eb0)

this pr: 20k nodes create 1272ms @ 35 MB HEAP: 

![image_2024_05_27T19_51_27_553Z](https://github.com/lightning-js/renderer/assets/1534440/5f9313fe-5368-412f-9f52-16a08244b870)
![image_2024_05_27T19_52_11_967Z](https://github.com/lightning-js/renderer/assets/1534440/840932ef-735e-405d-9eeb-a39c7604d8ed)


About 2.2x faster and nearly 50% less memory on an excessive stress
test.


Todo:
- [x] Fix RTT
- [ ] Fix/review VRT test results
- [ ] Run an app on it
- NoiseTexture: If cacheId not provided, don't cache the texture
Also
- NoiseTexture: If cacheId not provided, don't cache the texture

Fixes issue with the `threshold-texture-memory` test
Noticed this and wanted to fix it real quick
Slightly changed the checkRenderBounds function, and simplified the
emitting process according to the changes Frank made for PR #231
This refactor eliminates the ctxTextureCache WeakMap and replaces it
with access to CoreContextTextures directly from Texture objects themselves.

Since access is more direct and does not require a map look up each time
this change should be performance positive. It also simplifies the code
a good bit.

This is being done as a foundational step for further Texture memory work.
This refactor eliminates the ctxTextureCache WeakMap and replaces it
with access to CoreContextTextures directly from Texture objects
themselves.

Since access is more direct and does not require a map look up each time
this change should be performance positive. It also simplifies the code
a good bit.

This is being done as a foundational step for further Texture memory
work.
We are using the same calculations for the renderCoords we use in the
.addQuad function in the WebGLCoreRenderer, with this fix we can use the
already calculated renderCoords without having to do the calculations
again every time a draw call is made.
@frank-weindel frank-weindel changed the title Renderer v1.0.0-rc.0 Renderer v1.0.0-rc.1 Jul 8, 2024
Prior to this change, the VRT Dockerfile installed the latest
version of PNPM instead of that is specified in the project's
package.json (8.9.2 as of this writing). This led to an issue
where everytime you ran the VRT tests in --ci mode it would
run pnpm 9 which would incorrectly update the pnpm-lock.yaml
file.

This change uses `corepack` to install the project's version of
PNPM.
- Add an example project that shows how to create/install custom shaders/effects/textures
- Update README.md to show how to install fonts post core extensions
Prior to this change, the VRT Dockerfile installed the latest version of
PNPM instead of that is specified in the project's package.json (8.9.2
as of this writing). This led to an issue where everytime you ran the
VRT tests in --ci mode it would run pnpm 9 which would incorrectly
update the pnpm-lock.yaml file.

This change uses `corepack` to install the project's version of PNPM.
- Add an example project that shows how to create/install custom
shaders/effects/textures
- Update README.md to show how to install fonts post core extensions
@frank-weindel frank-weindel changed the title Renderer v1.0.0-rc.1 Renderer v1.0.0-rc.2 Jul 10, 2024
@frank-weindel frank-weindel changed the title Renderer v1.0.0-rc.2 Renderer v1.0.0-rc.3 Jul 11, 2024
TextureTypeMap was introduced when ThreadX was removed, and TextureMap existed as the
"instance" version of TextureTypeMap. This is inconsistent with the ShaderMap and
EffectMap, which don't have "instance" versions.

To fix this inconsistency, the "instance" version is removed and TextureTypeMap is renamed
back to TextureMap
TextureTypeMap was introduced when ThreadX was removed, and TextureMap
existed as the "instance" version of TextureTypeMap. This is
inconsistent with the ShaderMap and EffectMap, which don't have
"instance" versions.

To fix this inconsistency, the "instance" version is removed and
TextureTypeMap is renamed back to TextureMap
@frank-weindel frank-weindel changed the title Renderer v1.0.0-rc.3 Renderer v1.0.0 Jul 15, 2024
@frank-weindel frank-weindel added this pull request to the merge queue Jul 15, 2024
Merged via the queue into main with commit 9634e25 Jul 15, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants