You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in #59 I came upon a potential issue for how I currently handle Windows. To summarize, the window has a user drawable sub-canvas that it uses to separate what a WASM application can draw on from what the window library can draw on. This sub-canvas is twrConsoleCanvas containing an off-screen canvas so the WASM application can draw on it and allows the window to draw the sub-canvas on its main canvas.
The problem comes with the potential of closing a window where the problem becomes two-fold.
When "closing" a window, the window console should be deleted to free the memory it's using. However, there is currently no way to delete a console since they are all registered globally.
Additionally, a window should delete it's sub-canvas which has the same issue as 1. do to being a console.
So, my question is the following: would there be any issues with adding a function to "unregister" a library so it can be freed?
The main potential issues I can think of are as follows:
I would think it has all the same issues as using free() on memory in C except with the added challenge of being arbitrarily referenced by other programs.
There isn't really any way to track what applications are referencing a console other than the programmer handling it all themselves
For issues specific to windows, I think some potential ways to mitigate the above issues are as follows:
Send events for window close events
one problem is that with an async WASM program it might be possible for the program to be waiting on something when it gets the event and continue executing assuming the window still exists. It could also potentially happen with a sync program if the following somehow happens: window event is sent -> window is closed -> window event is handled assuming window is open -> window close event is received.
This could potentially be fixed by keeping the library/console alive until the close event is received and finished/acknowledged.
Directly bind a WASM program to a window so closing a window also closes the WASM application as well.
makes multiple windows harder requiring a WASM program per window with some communication protocol
Removes issue of window close acknowledgment
Make window and canvas operation return a boolean or something similar for the "success" of an operation so closed windows can return errors that C is able to handle and catch.
The text was updated successfully, but these errors were encountered:
Looking into it a bit further, it seems Windows method for this is with events like talked about above in conjunction with waiting for an acknowledgment. In this way, the application has the chance to cleanly handle the window closing and it's given an opportunity to cancel it. That way, if the program closes itself when the window does, they can stop itself from cloning while doing important tasks such as saving a file.
As mentioned in #59 I came upon a potential issue for how I currently handle Windows. To summarize, the window has a user drawable sub-canvas that it uses to separate what a WASM application can draw on from what the window library can draw on. This sub-canvas is twrConsoleCanvas containing an off-screen canvas so the WASM application can draw on it and allows the window to draw the sub-canvas on its main canvas.
The problem comes with the potential of closing a window where the problem becomes two-fold.
So, my question is the following: would there be any issues with adding a function to "unregister" a library so it can be freed?
The main potential issues I can think of are as follows:
For issues specific to windows, I think some potential ways to mitigate the above issues are as follows:
The text was updated successfully, but these errors were encountered: