I'm building a Windows Phone application that does video capture in a page and has a custom player in another page. I'm using my own custom codec so the player needs a lot of DispatcherTimer to keep track of several behaviors on the UI part and serve the movie at the good framerate in the codec part.
I'm trying to release all DispatcherTimer as I know they are CPU intensive, but even when stopping them my app is still very slow. If I press back-back then follow the flow, the speed divides by two each time. If I don't use my player, eveything is ok. And my player is only made of 3 DispatcherTimer, a FileStream and an Image box.
I feel that DispatcherTimer are still running in memory and are double-instantiated even if they are instantiated as private on the page directly.
Can I force the page to release all this stuff?
Actually I don't understand yet what is the difference between navigating to a page next to current page, or navigating back. I don't know i.e. how the page is shown again without calling InitializeComponents, so I'm mixed up about which resources to release, and which resources to keep intact.
My execution speed problem was really caused by some running DispatcherTimer, so I'll answer it to have it archived.
The solution:
Ensuring that all DispatcherTimer has been instantiated directly on the page so that we can nullify them from anywhere in the code.
In OnNavigatedFrom, I kill the DispatcherTimer and in OnNavigatedTo, I recreate them with myDispatcherX = new DispatcherTimer();
No "temporary" timers, like "DispatcherTimer myTempTimer = new DispatcherTimer; with ((DispatcherTimer)send).Stop() in callback, as chances are that it remains in memory in an application where we navigate.
Related
My app creates a window with a local page that requires node integration to be enabled.
After I click a button on this page, I am navigated to a third party page.
Because I want node to be disabled in this third party page, and I can't toggle node integration in a BrowserWindow, I load this third party page in a sandboxed BrowserView that is embedded inside of the window and is stretched to fit the entire screen.
Now doing this navigates the embedded view, but the BrowserWindow is stuck pointing to the old local page that is no longer relevant.
To prevent this extra page from sitting around in the background, I navigate my BrowserWindow to "about:blank" to effectively clear it out and make room for the BrowserView.
I am realizing now that while this "clears" out the old page, it keeps the renderer process that's associated with it alive. From here:
Chromium creates a renderer process for each instance of a site the user visits
And understandably, navigating to "about:blank" doesn't signal to Electron that it should kill the other process.
I want to get rid of this renderer process, so it doesn't sit around unnecessarily and use CPU and memory when I interact with the window.
Two things that have worked:
I removed the extra navigation to "about:blank" since we're now killing the process and:
1) When my button in my renderer sends a message to the main process telling it to create a BrowserView and navigate to the new site, I do a process.exit();. I guess a part of me is nervous about the process exit interfering with the message that gets queued up for main, though it seems to work fine.
2) Instead of killing the process from the renderer, I created and navigated my BrowserView and then ran a little browserWindow.webContents.executeJavascript("process.exit()");. I find this uglier, though it does mitigate by concern above in #1.
There isn't a webcontents.destroy() type of method, and I don't know of a way to signal to Electron that it needs to destroy this unnecessary process.
I suppose I might have a pretty unique case, but is there a nicer way (or more standard way) of handling this than explicitly doing a process.exit()?
There is now a WebContents::forcefullyCrashRenderer() API that accomplishes this (introduced by this PR):
Forcefully terminates the renderer process that is currently hosting this webContents. This will cause the render-process-gone event to be emitted with the reason=killed || reason=crashed. Please note that some webContents share renderer processes and therefore calling this method may also crash the host process for other webContents as well.
As of now (July 2021, Electron v13) - there's also an undocumented webContents.destroy().
https://github.com/electron/electron/issues/10096
As the documentation mentions, some webContents share renderer processes and if you use webContents.forcefullyCrashRenderer() you may terminate them as well.
I'm not sure about how webContents.destroy() handles it, but from the name it seems to be more narrow in scope. I would assume that it kills the renderer if webContents is the only webContents attached to it (I tested this) and spares the renderer if other webContents is using it (needs confirmation).
I'm new to UWP (windows 10), working on an app for windows phone, I wanted to know what is the difference between:
Using multiple frames and navigate from one to other.
Using a single xaml with no frames but with multiple grids (or other patterns), and instead of navigate- just change visibility so only the desired grid will be visible.
which option is better? and why?
The system keeps track of the Page you are currently on. So even when your App exists and even if it's removed from memory the OS can tell the App to reopen on that page.
Similarily when your App provides other Apps with the capability of calling into it to open certain file types of to perform certain actions (e.g. start navigation, etc.) pages will be used.
Lastly if you put everything on a single page and just manipulate visibility this will increase memory consumption of your App (as everything needs to be loaded even if it's not visible) and it also might increase load times.
Of course how much that impacts you is up to the type of App you are building. In general however I'd advice you to start building using separate pages in case your App grows. Also you get a lot of stuff out of the box if you do so (e.g. animated transitions, etc.)
I am new to windows app development. I am currently working on an Universal App using c# and XAML, which has 4 pages, first page being a welcome page. I have to check on other 3 pages (other than welcome page) that if the page is idle for last 2 minutes then I have to reload the welcome page, forcing used to start from the beginning. I did research on this on google, but couldn't find anything helpful. Hope someone from stack overflow community can direct in right direction.
Thanks,
Kevin
Is the welcome page for a login? If you are requiring the user to login to view the extra pages you will also have to handle when the app is in the background. In app.xaml.cs, subscribe to the corewindowvisibilitychanged event. Save a time stamp and now you can check how long the app has been in the background and navigate to the welcome page in the I launched event.
To implement an idle timer you should look at the I launched event where the root frame is created. Subscribe to the pointer moved event in the maimwindow, or use a base page for the similar three pages in your app. When pointer moves, start a dispatcher timer that will be your ticking time bomb for when the navigation occurs. If the pointer moved event happens again, call dispatcher timer.stop, null it out and start a new one. You may also want to subscribe to keyboard events too.
Don't forget to subscribe to pointer moved from the c#, so you can use the overload to handle all events, even when an originating source has already handled it. :)
I have found that in Windows 8 apps, a Page's constructor always gets called again when navigating back to this page, however this is not the case in Windows Phone 7 apps.
Because of this behavior all the properties of that page get lost and you need to somehow store them and reassign them after the page is reactivated. At the moment I am using the SaveState method to save the data and reassign the data in LoadState method. Both of the methods are built-in in the sample Grid/Split App.
I wonder why it's designed this way and if there's any better way to maintain the instance of the page?
You can set Page.NavigationCacheMode = NavigationCacheMode.Required for each page you want to keep in memory, but note that you have to make sure users can't navigate through these pages endlessly as that would leak memory.
I've posted about this before but have been struggling to come up with a solution.
Basically I have a HTML5/jQuery app within my iPad app. Every time I load an image into the UIWebView (HTML App) the overall allocations in the profiler increases by about 2MB each time. This sounds about right because the image is approx 2MB's. I am using the data notation in the tag to load a Base64 image.
i.e.
When I load a certain number of images (page turns) the app will crash.
The app is an ebook viewer, so when I turn to a new (not previously loaded in current session) the allocations increase. But, if I turn back to a previiously loaded page the allocations don't increase and the page loads quicker than a new one. Every page turn sends a request to the database so i'm beginning to think the leak isn't in the iOS and that it could be in the HTML5 app.
Any ideas on this? I guess there could just as easily be a leak in the HTML app as there could be in iOS. How do I go about debugging this?
Any ideas greatly appreciated.
Thanks
HTTP and WebKit likes to keep a local copy of resources, just in case you will need it again. This may be what you encounter.
Check the answers to this question: Is it possible to prevent an NSURLRequest from caching data or remove cached data following a request?
This was die an unfixable issue with iOS 4.
Issue resolved itself after upgrading to iOS5.