My app has a lot of API calls and image downloads, that's why i'm using Cache Manager package.
I noticed a lot of content is re downloaded and my app sends API requests without me doing anything but scrolling the screen.
I started checking and the build() method does gets rebuilt any time, but it has nothing to do with any setState() calls whatsoever!
Is there a chance the garbage collector or cache issues have something to do with that?
I get a lot of debug prints like Background concurrent copying GC freed 368(32KB) AllocSpace objects, 18(1632KB) LOS objects, 56% free, 1202KB/2MB, paused 25.610ms total 107.349ms.
If not what can cause it?
Well i deleted the question but thought about it and un-deleted it to answer with the solution if anyone else will ever encounter such a behavior:
It is very weird but seems like the problem was having my widget as a child of a RefreshIndicator widget.
I'm sure i didn't even scroll to the position it should indeed activate my refresh method, but scrolling any direction too far (even horizontally while my refresh indicator was a regular vertical one) activated it for some reason.
Sorry for not providing any example while asking the question, the app was too complicated and i didn't even know what is relevant and what's not...
Edit:
Now it's just a real mystery, i added a print('Refresh') line to my onRefresh method, and it never got printed, even when the widget got rebuilt!
If anyone have some kind of explanation i would really like to hear it.
Related
The database application I am working on can have a window with multiple NSTextView elements for displaying and editing data. When the current spot in the database is repositioned, all of the NSTextView objects in the window need to be updated with new contents. This is done with a loop that scans each object and checks to see if it needs to be updated. If it does, the new value is calculated, then updated by using the [NSTextView setString:] method. Here is a simplified version of the code involved.
for formObject in formObjectsInWindow {
NSTextView * objectTextView = [formObject textView];
NSString * updatedValue = [formObject calculateValue];
[objectTextView setString: updatedValue];
}
This works, but if there are a lot of objects, it is somewhat slow. Probably related, the display does not update all at once, you can actually see a "ripple" as the objects are updated, as illustrated in this movie (this movie has been slowed down to 1/4 speed to make the ripple effect more pronounced, but it is definitely visible at full speed).
If you've gotten this far, you might suspect that the calculateValue method is slow, but that isn't the problem. In other places the same code is used and runs at tens of thousands of operations per second. Also, this delay only occurs during update operations, it doesn't occur when the window is first opened, even though the same calculations are required at that time. Here is an example. Notice that when I switch back to the detail view all the NSTextView objects update instantaneously, even though the record changed and all of the values are different.
My suspicion is that the [NSTextView setString:] method is updating the off-screen buffer, then immediately copying that to the on-screen buffer, so that this double buffering is happening over and over again for each item, causing the delay and ripple. If so, I'm sure there must be some way to prevent this so that the screen is only updated at the end after all of the values have been updated. It's probably something simple that I am missing, but I'm afraid I am stumped as to how this is supposed to be done.
By the way, this application does not use layer-backed views, and is not linked against the QuartzCore framework.
I brought up this question with Apple engineers at the WWDC 2018 labs. It turns out the problem is that the setString: method does not mark the NSTextView object as needing display. The system does eventually notice that the text has changed and updates the display, but this happens in an asynchronous process, hence the "ripple" effect. So the workaround is simply to add a call to setNeedsDisplay after calling setString.
[objectTextView setString: updatedValue]
[objectTextView setNeedsDisplay:YES];
Adding this one line of code fixed the problem, no more ripple effect.
I'm told that this is actually a bug, so hopefully this extra line won't be needed in future versions of macOS. As requested, a radar has been filed (41273611 if any Apple engineers are reading this).
I am currently updating my app, and I have been facing a very strange and complex problem for the last few days. The part of the application that is problematic is made of one UITableViewController that is a list of news, and (after you click on a news) a detail view which is in fact a UICollectionView with as many details CollectionViewCells as there are news.
Each of these can have an infinite amount of elements, and are loaded 20 by 20 when the user scrolls to the bottom of the TableView (or to cell that is at the furthest position right on the CollectionView). Also, inside a DetailsCollectionViewCell, there can be another UICollectionView, containing images.
My problem is that after scrolling a few details views, after behaving normally (ie memory is allocated when I change the page, then stabilize until I change the page again, and so on), the memory allocation start to ramp up slowly but steadily, even if I stop doing anything at all. Also, the CPU usage will go to 100-120% and stay there, whatever I do, even, again, if I don't touch anything. After a while, the UICollectionView and the UITableView will not render any animation anymore, thus loosing the paging, and the inertia when scrolling, and overall resulting in a very poor user experience.
The strange thing is, I can observe these behaviours via XCode 5's Debug Navigator, but when I try to use instrument to find the source of the leaks/allocations, the allocation graph is normal, and I get 40-60 MB mem usage, no more, despite still observing the animations/paging problems.
Has anyone already met such a strange behaviour, and can someone help me in finding the cause of all this fuss ? (maybe by fixing Instruments ?)
Thank you all in advance, don't hesitate to ask me for more infos if needed !
I found the solution to my problems in the meantime.
About the difference in Memory usage between Xcode 5's Debug Navigator and Instruments, it was caused by my use of NSZombies. I have the habit of always setting them on, and that just flew off my mind... To remove them : Product > Scheme > Edit Scheme > Diagnostics > Enable Zombie Objects (just unmark it).
The cause of my CPU usage was an animation that was going on indefinitely in the background on multiple pages. The solution was to first of all stop it as soon as it is not seen/useful anymore, the optimise it by changing my approach (I was using CAAnimation and moved on to using UIView's animate function).
I think I might have pulled the trigger a bit too fast here, but hey... if this can help someone later, then it will not be a waste !
Okay, as Title says.
For example, i use NAudio to playback what i record (loopback if you want).
And if i click on the GUI (the top part, so i can move the window).
It will cause a "sleep", and when that happens the current activity (Audio playback) stops.
And then it continues afterwards.
But i want to remove that, as i don´t know any other application that has it, so it´s probably something to do with how i am programming.
Please keep it simple, i am extremely new to c#.
I am guessing on Bakckgroundworker or something, but i couldn´t get it to work.
So hopping for a more concrete answer.
This was just me not understanding that using the Main Thread in a window form will cause anything on the GUI to be run on it.
Meaning, if i move the GUI, that movement will be Priority over the rest of the code, so everything else will get paused if run on that thread.
Perhaps it differ from object to object, but in this scenario it was the case, so i just moved it to a separate thread and it´s solved.
From time to time, one of my apps experiences a delay of 2-10sec whilst dragging an object in a complex view. In some cases, the delay is sufficient to cause the wait cursor (spinning pizza of death) to appear.
Time Profiler reveals nothing very remarkable -- just the expected drawing calls to update the view as the object is dragged. (This is a lot of computation, but I see no obvious difference in the profile during pauses and between pauses.)
Memory profiler reveals nothing special about the pauses. Allocation seems flat throughout the drag. Leaks is clean. (My initial assumption was that I was spinning off too many autoreleased objects, but that doesn't seem to be the issue.)
Activity Monitor indicates that during the drag I'm pretty much using up one core for all the redrawing. That's what I expect.
Any ideas of where to look next?
Hmm. Well maybe you could try running Instruments.app with 'Record Waiting Threads' enabled. This will show you where the code is waiting as well as running. You might be sitting in a semaphore or doing some IO- that will show up in this mode.
I am working on a short animated story, which has a scrubbable timeline and chapter headings. I used TimelineMax for sequencing it. For the most part, it is working fine. I am seeing some strange behavior that pop up, though: sprites disappear, functions stop responding to user input, seams of the sprites become transparent -- all small issues but pretty hard to nail down because they happen in Mac only.
So I am wondering what is wrong with Flash, and why it misbehaves on a Mac?
I frequently work on the same projects on Windows at work and then my Mac at home. I also see some difference on the Mac compared to Windows. I find that various Flash Player versions for the Mac are generally slower than the Windows players, and I've seen some odd behavior on the Mac that is not happening on Windows.
In most cases I've narrowed this down to AS3's garbage collection. Garbage collection happens when the player determines that an object no longer has a reference in the movie, so it removes that object to free up memory. Let's say you have a class method like this:
function myTweenFunction():void {
var myTween:Tween = new Tween(myDisplayObject, 'x', Strong.easeInOut, 0, 500, 10, true);
myTween.addEventListener(TweenEvent.MOTION_FINISH, onMyTweenDone);
}
The method above will tween myDisplayObject's x value from 0 to 500 over the course of 10 seconds. When that tween is done, it should fire the onMyTweenDone method (not shown). However, myTween was created inside myTweenFunction so it only exists in the scope of myTweenFunction. When myTweenFunction is done, the myTween object is no longer referenced by any object in the movie so it becomes a candidate for garbage collection. You will start to see the tween, but at some point it will stop before it gets to 500 and the finish event will not fire. This means that myTween has been destroyed. To fix this problem, myTween needs to be a member of the class, or just needs to have a reference outside of a class function.
Getting back to the Mac vs. Windows issues, I see that garbage collection on runtime-created objects on the Mac is more apparent than on Windows. Garbage collection happens in the Windows Flash Player, but the tweens and other events may be finishing before garbage collection occurs since the Windows Flash Player has better performance. If the Mac Flash Player is slower (ie. the same tween might take longer), then the garbage collection might happen before the tween is done. Garbage collection does not occur frame-by-frame like an animation; it's a background process that can happen at any time, or not at all if there's enough memory for the Flash Player. Your windows machine might have a pile of RAM and the movie can play fine without the need for garbage collection, so myTween might never go away. If your Mac has less memory, or if you have a ton of apps open at once and the Flash Player memory allotment is limited, then the Flash Player will perform garbage collection more frequently.
I've also used TimelineMax, and there's an auto garbage collection feature that is turned on by default. Try turning that off and test on the Mac.
Ultimately, you should design your project with the assumption that a user may have very limited memory, so your objects need to be created, referenced, and garbage collected accordingly.
I've encountered some rendering issues between plugin versions especially when dealing with transparency, fonts, and embed settings.
If you are doing this in a web browser try playing with the WMODE embed setting and see if your results change.