I have a feeling some regression has taken place in regards to cooktime of Textport/ DAT rendering.
Example 1:
The example attached with a single CHOP to DAT converting 6 channels of 2400 samples takes TD framerate down from 60 to 33fps, with cooktimes for the DAT taking 8-20msec.
The conversion back to a CHOP takes only 1msec.
Example 2
In the attached example, the CHOP Exec DAT prints every value of the LFO to textport.
If I open the textport, TD starts to freeze / framerate crawls to a halt to ~2fps.
Example 3
Sometimes when I open a DAT and enlarge it so it almost fills my whole screen, my framerate drops 50%. I did not succeed yet in making a reproducible demo of this (perhaps this is actually caused by examples 1 or 2 ).
Do you have a build to compare with in mind? should I go back to 2020.xxxxx?
Sadly I can’t reproduce here, I see an “expected” drop but going down from 60 to 50-55. Closing all active viewers and just opening textport, there is no drop and it’s a stable 60fps. I’m comparing between the latest stable (12380) and the most recent internal build on that branch, no difference.
It reminds me of a bug we had logged internally where zooming on the line numbers would cause heavy frame drops, but marked and confirmed as fixed in 2021.12550. Just tested it again and it’s still around unfortunately. Can you try and load a large block of text in a text DAT (lorem ipsum or something), hide the viewer and then drop a parexec DAT next to it. Then zoom in fully, with a focus on looking at the line numbers. Is that reproducing the bug you are seeing?
Edit: Tested in 12800 as well:
2. I don’t see any difference. Could it be that number 3. caused some confusion ?
actually no - I just feel it’s very slow and I thought it used to be faster, but could be my imagination
weird thing is I also can’t reproduce 2. anymore when running that tox in a freshly started TD - but I 'm sure it happened before as I could make that reproducible example. I had a project were loads of text to textport for debugging was slowing everything down. Actually when it was static in the textport it was fine, but when I scrolled in the Textport to the top, TD started get slower and slower, when I was at the top it was the slowest. When I scrolled back to the bottom all was fine again. Sounds weird huh.
wooha, and I thought this was perhaps caused by me working too late at night, but hey, it turns out I’m not (that) crazy! Zooming in with line numbers in view does drop the framerate ~50% indeed.
I had a project were loads of text to textport for debugging was slowing everything down. Actually when it was static in the textport it was fine, but when I scrolled in the Textport to the top, TD started get slower and slower, when I was at the top it was the slowest. When I scrolled back to the bottom all was fine again. Sounds weird huh.
For point #1, although things didn’t seem to get slower, I did take a pass as improving our float->string conversions routines and now the cook times for those DATs are about 60% faster in the 2021.30000 series now. Thanks for the sample!
).