02-27-2023, 04:30 PM
Do
For yy = 0 To 239
For xx = 0 To 319
X3D = ((xx - 160) / 160) * 3
Y3D = ((yy - 120) / 120) * 3
_PutImage (xx, yy), P(xx, yy)
Next
_Display
Next
The problem is in the above.
Each screen is 320x240 pixels, with 4 bytes per pixel in colors, for 307kb of memory. The FOR xx loop is running 320 times, before any _DISPLAY is ever called, so that's 98,304,000 bytes of memory in use before the _DISPLAY is called.
Hardware images all stay in memory and only render once _DISPLAY is called, so that inner loop there is using 98MB of VRAM with each iteration -- which by itself wouldn't be a "memory leak". Where the memory leak is occurring is with the FOR yy loop being called 240 times without any delay, which is putting 240 blocks of 98MB chunks of images up into VRAM. This memory is being drawn to and used, faster than it's being freed. It *IS* being freed (if it wasn't, it'd quickly use 23,592,960,000 bytes of VRAM); it just isn't being freed as fast as it's being allocated and used.
On my system, things will begin to balance out around 3.7GB of memory usage; as that's the point where we finally start to free those extra handles as fast as we create and allocate new ones.
I don't think this is a true "memory leak", in as much as it's just the nature of video memory -- priority goes to creating and processing your video commands, over freeing and releasing unused memory. In this case, you're simply just creating and using the memory faster than the OS is freeing it. Add a delay of any sort into the process, and the issue qill quickly go away.
For yy = 0 To 239
For xx = 0 To 319
X3D = ((xx - 160) / 160) * 3
Y3D = ((yy - 120) / 120) * 3
_PutImage (xx, yy), P(xx, yy)
Next
_Display
Next
The problem is in the above.
Each screen is 320x240 pixels, with 4 bytes per pixel in colors, for 307kb of memory. The FOR xx loop is running 320 times, before any _DISPLAY is ever called, so that's 98,304,000 bytes of memory in use before the _DISPLAY is called.
Hardware images all stay in memory and only render once _DISPLAY is called, so that inner loop there is using 98MB of VRAM with each iteration -- which by itself wouldn't be a "memory leak". Where the memory leak is occurring is with the FOR yy loop being called 240 times without any delay, which is putting 240 blocks of 98MB chunks of images up into VRAM. This memory is being drawn to and used, faster than it's being freed. It *IS* being freed (if it wasn't, it'd quickly use 23,592,960,000 bytes of VRAM); it just isn't being freed as fast as it's being allocated and used.
On my system, things will begin to balance out around 3.7GB of memory usage; as that's the point where we finally start to free those extra handles as fast as we create and allocate new ones.
I don't think this is a true "memory leak", in as much as it's just the nature of video memory -- priority goes to creating and processing your video commands, over freeing and releasing unused memory. In this case, you're simply just creating and using the memory faster than the OS is freeing it. Add a delay of any sort into the process, and the issue qill quickly go away.