Closed arnabanimesh closed 3 years ago
If you look at all examples for minifb they do
while window.is_open() && !window.is_key_down(Key::Escape) {
...
}
I think you should change the code to not use loop
but something similar to this above.
There should be an assertion of some sort so that this kind of error/warning is shown to the dev in order to avoid unnecessary background tasks.
I'm not sure I follow? The window should be released correctly if you use the code above, currently the loop you have never breaks thus the window will never be freed.
I am just saying that by default the syntax should be such that when the window closes, the program is also freed from the memory. If syntax modification is not possible to promote such behavior, a warning message should be at least provided at compile time to warn the dev that the event loop has no break and the app will continue to run in the background even after closure. You know, how rust promotes safe coding practices.
Just consider a careless new dev using templates from online and doing coding. If he distributes such apps to the end-users, their system is gonna slow down, and they won't even know that because they opened that app multiple times.
Every GUI framework like Qt, wxwidgets frees the memory when window is closed.
Your code is working fine btw. Thanks.
Yes, minifb will also free the memory when the window is closed, but your application that is just within a loop { .. }
never exits, thus it can't free it.
I was trying out this example.
When I compiled using
cargo r --release
window opened up properly. But when I closed the window using cross button at the top right-hand corner, the window closed, but the process wasn't released. In the terminal I had to press Ctrl+C to exit to the prompt.Closing the window should release the process from memory immediately and cargo should be able to understand what's going on.
For the record, I use
Windows 10 Home 1909
.