Rendering performance / customop / userops

[jbrun80]

Hi guys! I have to render 13 images. For now I am using one rectangle op for all of them, with alternating textures and width. The performances of my patch are very low. Any advice on the fastest way to render 13 webp images?

I also get this in the performance op: Warning Not-Typed Buffer Attrib! (mesh rectangle:attribBiTangent)

And a lot of [Violation] 'requestAnimationFrame' handler took ms in Chrome's console.

Thanks a lot!
It is a pretty big patch, which is getting very slow also on the editing side (sometimes I have to wait more than 5 seconds to connect a chord between two ops and scrolling through the patch gets all laggy).

[steam0r]

hey,

it would be helpful if you could share the patch. this sounds like you are doing something weird ;)

maybe this guide to performance optimizing can help pin down the issue and creating a smaller, presentable
patch that outlines the problem: https://cables.gl/docs/9_performance_optimization/performance

best,
stephan

[jbrun80]

Hey Stephan,

Thank you for your reply!

Here is the patch: https://cables.gl/p/615c4804a279e6427ca1fa54?s=T4rfCDwNyVGYMZ53

Let me know if you want me to send a smaller version with the rendering part only?

Yes, I have read your performance tutorial and I have tried to optimise as much as I could with the performance/profiler/console.

Thanks a lot and happy to answer any question.

[steam0r]

hey,

a smaller patch would be nice, this is really big. from the first looks of it though it seems like you are updating a lot of arrays under the repeat. this basically means that they are being updated and read 13 times per frame...is this really neccessary?

a smaller patch might help finding out the problem.

best,
stephan

[jbrun80]

Hi!

Thank you for looking at my patch. Yes, it's quite big.

Here is a smaller patch with only the rendering part: https://cables.gl/p/620e098fcc112e11515b18e4?s=OaQxL1Gf9U7snAUG
The rendering part is based on the "repeat" example: https://cables.gl/edit/VFAfgg

I made a small modification to stop the last array rendering 13x times per second. It doesn't improve the fps.

This smaller patch is much more reactive for the editing. Does this mean that the editor gets slower with a lot of ops? If yes, is there a strategy to split a big patch into something not laggy?

Let me know what you think and if there is a better rendering version for my 13 images.

Thanks a lot!

[steam0r]

the smaller patch runs fine for me, until i "enable debug":

can't really find anything wrong with it, maybe someone else can take a look. then again your original patch has A LOT of customops that seem to be exact copies of the original ops. is there are reason for this? i can't debug your code...sorry ;)

as for "other approaches", maybe these patches can help a bit: https://cables.gl/tag/gallery

[jbrun80]

Thanks a lot for checking!

So you mean that the performance op creates this error/warning?

Yes my original patch has a lot of custom ops, they are not exact copies to the original ops, they always include a minimal modification. For example showing the fps on the op directly, as you show on your screen capture. Or sometimes not outputting a "null" before the value/array as it created problem further. So they shouldn't be slowing down anything in theory, as they are also mostly inactive when not navigating.

I will also have a look at the other patches, thank you.

[steam0r]

customop loads code after the editor has been initialized and also per-op, so if you copypaste Rectangle and use that CustomOp multiple times (say 3) you now loaded the code for Rectangle four times (one original and your three custom implementations). i am not sure how but this will definitely impact performance somehow. as for the "FPS has number next to it" maybe take a look into the "viz" ops, especially viznumber:

https://cables.gl/op/Ops.Ui.VizNumber
https://www.youtube.com/watch?v=-1vMiU6BcDg

[jbrun80]

Oh I see! So that is not a good thing indeed to have so many custom ops. Should I better transform them into clones and then modify the clones? Would that help?

Thanks for the viz ops!

You spoke about "until i "enable debug"", does this mean that for you enable the performance op creates the "WARNING: not-typed buffer attrib" and that I shouldn't look further into this error?

[steam0r]

for loading purposes it would make more sense to clone the ops and have them as a userop instead of a customop, if you REALLY need these modifications, that is.

please understand that we cannot debug your custom code, at all :)

what i meant with "enable debug" is this branch of your patch:

this slows stuff down a lot, which is expected, i guess. if i do not have this enabled the (smaller) patch runs fine. i hope you have enough material to investigate further ;)

[jbrun80]

I changed all my custom ops with cloned ops, the editing flow is better. Not completely smooth yet. I continue searching.

I get these errors from the console:

[glrectinstancer] rectinstancer textrects_mainText resize to 6000
info @ logger.js:40

cables.min.js?nc=1644501123821:1 WebGL: INVALID_VALUE: bufferSubData: srcOffset + length too large

Any idea, where these point at?

Thanks a lot!

[jbrun80]

Hi!

I am continuing my way towards optimisation.

I did some tests with the profiler and it seems that some of the ops rise in usage when they are used, but don't come down when they stop being used.

For example, you see here, that the SUM and Modulo ops have risen when I started using them (by navigating in my canvas), but stay very high in the usage percent, even though I have stopped using them for a few minutes:

Any idea why this happens like this?

This doesn't only happen in my big patch, but also it the smaller one I made for this thread.

Thanks a lot for your input!