Let me start with the cursor issue, because it is not related to the memory leak:
TheOm wrote:Usually this mouse cursor issue happens if you call showCursor in mouseLUp instead of mouseLUpCaptured.
mouseLUp only gets called if the cursor is over the view (which it might not be if you captured the mouse).
Indeed, TheOm spotted the issue. I created the knob long before we were aware of the mouseLUp issue. mouseLUpCaptured was never documented, so we all used the prior. I used the "Show Cursor" prim to keep the mouse in place, and this prim needs a boolean, which is switched by mouse down/up events. I will correct the issue and post on Flowstone GURU.
So, I used a vector knob for a specific reason; to exclude any issues that might arise from reserving memory for pictures converted to bitmaps. This knob only uses the view bitmap (draws directly to the view). Also, the test is reduced to pure Ruby, to concentrate on this issue alone.
It is totally normal for any process to increase memory usage during execution. It can't foresee the future. If things are defined later, bitmaps get loaded in later, audio is recorded to mem, etc., it will reserve that amount of memory during execution, not in the beginning. And of course it can't release memory that's still being used.
But there's also a clear difference between normal memory increase and a memory leak. In the first dll (the one I posted), there obviously is no memory leak. It acts as expected (yes, we ignore the cursor issue).
The second one (posted by Adam), does have a typical memory leak.
Both are exactly the same schematic. Both are exported exactly the same way. But, number one was created with 3.0.6 and number two with 3.0.8.1. The comparison was important to exclude the rumours that there would still be an old synthmaker leak in there.
The issue therefore is reduced to one spot for MyCo to look at: The export mechanism. Something has changed between 3.0.6 and 3.0.8.1 in the way Ruby code is embedded during export. It might be another Ruby version or a mistake in the programming of the export routines (I wonder what would happen if Ruby got loaded with every knob move
). There's still a lot to investigate. But MyCo can concentrate on the export routines and dependencies and I hope this saves him a lot of time.
But let me also be clear: It is not an issue from Ruby.
Posted: Mon Jul 17, 2017 1:08 pm
