In an attempt to optimize my app's performance, I've tried to cut down the number of elements in its main carousel as much as possible. I'm down to 3 first-order items (the one being viewed, along with N-1 and N+1).
I'd also like to cut out most of the contents of the N-1 and N+1 carousel items and programmatically add the contents for the item that is currently being viewed (so that the carousel items would look like this: http://i.imgur.com/gm7cL7E.png).
activeItemChange is the obvious choice here for the event listener. Problem is, it apparently is relatively slow, especially on low-end Android phones. It can take as long as 4 seconds to fire.
I've tried the carousel's onDrag property as a different way to fire the content creation, but asking the phone to do two operations (animate the carousel moving & create the new content items) makes the carousel movement animation choppy.
Is there any way to modify activeItemChange or the carousel to improve the listener's firing speed? Or any other listener I could be looking at that would perform better? I've done quite a lot of work optimizing overall performance on the app (shrinking the DOM, event delegation, etc) and the rest of the app runs quite well, so I'm not sure that doing general performance work will free up sufficient CPU to get activeItemChange to the level that I'd like.
Edit: I've done even more performance improvements in an attempt to free up enough CPU, to no avail. Any additional tips would be greatly appreciated.
Edit 2: It's been suggested to use order: 'before' for the event, as in:
listeners : {
order : 'before',
activeitemchange : someFunction
}
That does fire much more quickly. However, since activeItemChange has necessarily not been fired yet, I can't determine which item should get the carousel contents added. If I could determine which direction the carousel is going, that would be sufficient, but I can't seem to get that either.
Additionally, since Sencha seems to automatically paint N+1 and N-1 and erases N+2 and N-2, I was thinking I could use that as a more rapid determinant of where the item is in the carousel; unfortunately, based on the performance issues brought up in the Sencha documentation, it seems like it would end up with worse performance rather than better in the end.
Good question. Just a suggestion may or may not work. Instead of concentrating on the activeItemChange of the carousel maybe you could try the painted event of the container into which you want to put your items, or initialize event if the data is not going to change, initialize is faster than painted but only fires once so if your content is going to change use painted, otherwise try it out with initialize it may be the better way to do it.
Related
To be short, my requirements are:
The list needs to contain about 5 thousand average product cards in two columns. The products are splitted into sections.
It must be performant, really performant
I need it to work well with onViewableItemsChanged method
I need to be able to scroll it to the desired position as quick as possible
It must be able to be Animated with the native driver (e.g. to animate header according to the scroll position)
I've tried to use SectionList for my purpose, but it did not achieve the desired performance despite many tweaks of the virtualization parameters. The problem was that the responsiveness of the app gradually got worse as I scroll down. It was because of the amount of items above the viewport. Yes, SectionList do detach the items outside the viewport, but it replaces it with the getItemLayout function, which floods the thread and hangs the app for about 3-4 seconds before it starts responding.
Another way I tried was to use react-native-big-list. This thing works really well with lists like mine, like really fast, exactly how I need it to work. But sadly it is not perfect and has some unsolved issues:
the onScroll method here does not work with Animated.event with the useNativeDriver prop set to true
the onViewableItemsChanged stops working as soon as I reach the second section of the lists
the scrollToLocation method does not support the viewOffset prop.
All the issues above are known but still not resolved, and I am not as good to somehow patch them (in fact I tried)
I do hope that someone have the same problem solved.
Sorry for my mediocre English, but hopefully I expressed my thoughts good enough to be understandable
I have a timeline where I basically want the user to have the ability to tap on the screen to fast forward the animation (well, more like skip part of the animation) to a later part. Obviously, this would have to be done using code.
I've researched this quite a bit and I don't think there's an easy solution. CCBSequence and CCBSequenceProperty offer a bit of hope, but my ideas have run dry and can't see a way to do it.
Obviously I'm aware of the animation manager and using it to run timelines and stop timelines, or even call something when the timeline is completed, but my capabilities with manipulating timelines made in Spritebuilder doesn't extend too far beyond that.
I can think of a messy workaround, where basically I just duplicate the section of the timeline I want to skip to and when the screen is tapped stop the current timeline and go to that, but it seems cumbersome and messy and I'd like to avoid that if possible.
Thanks for help!
I found the easy solution after a bit more looking
So if you have a look in CCAnimationManager there is a method for this called:
- (void)jumpToSequenceNamed:(NSString*)name time:(float)time;
So with your node you can call
[node.animationManager jumpToSequenceNamed:#"MyTimeline" time:1.0]; // 1 Second
If your animations aren't extremely complicated, try to implement it via cocos2d actions http://www.cocos2d-swift.org/docs/api/index.html
Using engine API you can create animation with custom speed on every tap.
According to a Qt blog post from 2011, there is supposed to be an environment variable QML_FLASH_MODE that can be set to 1 to see which areas of a QML application are being repainted.
I have set this variable for a Qt Quick 2 application that I'm writing and there is no visual difference to running the application without this variable.
Is there any other way to see QML redrawing activity? I'm trying to troubleshoot performance issues.
It looks like QML_FLASH_MODE was removed in this commit as part of refactoring to support separate rendering loops per window. Reason why it was removed is not obvious, but anyway its gone now.
If you think QML_FLASH_MODE will help you to analyse your scene, you can always get back to Qt 5.1.1 where it still should be present.
On the other hand, to visually analyse scene is not always efficient. I suggest to use qtcreator's profiling. Take a look at property bindings that reevaluated just before painting happens. This should help you to figure which property changes have triggered redraw and could give you some hints on how to optimise your scene.
If you just want to count fps or log when frames being painted, check QQuickWindow::frameSwapped signal.
I have been searching around and it looks like this question has been asked quite a few times in various places with no answers or responses. That means that I can't be the only one experiencing this.
There is always a delay in the scrolling when you try to scroll a list or panel for the first time. After the first time you scroll a list or panel, there is no longer any delay. Is there a way I can simulate this "first touch" in an effort to remove the delay when attempting to scroll a list or panel for the first time?
I've been looking through the ScrollView and Scroller code and have not been able to find a point where anything heavy or expensive is happening on a first touch.
Any help or direction on how to remedy this would be greatly appreciated.
Thanks!
You can open the Chrome/Safari developer tools and start profiling("Profiles" tab) to see if there is any JavaScript code that is performing badly and causing the hang.
If it's not code that hangs, it might be a web browser issue (e.g. image cache allocation), for example due to the first time that things dynamically change in your web app.
It's also important to try and compare platforms and see if they have the same issue.
It's also often helpful if you specify the Sencha version (I assume 1.x?) and the platform(s) you've had the issue with. iOS/Android/PC can often react quite differently.
First of all, I know there are a few other StackOverflow questions about this subject, but I have read them all and I still am confused about what to do for my situation. I'm probably missing something obvious here, if you could help clarify that would be much appreciated!
I have a app which is doing a lot of work to animate images within a view - mainly comprised of a number of images moving in straight lines for a second or two at a time. I considered at first making them all simple, once off animations using UIView animateWithDuration for the whole duration of the movement. But I found that didn't give me a lot of power to intercept the movement or stop it or check where it was up to, so I scrapped that. My new approach is to use an NSTimer, firing 20 times per second, doing incremental movements. This way I also can intervene (almost) instantly to change the animation or stop it or update a status label based on how far through it is, etc, etc.
First of all...there probably is a better way than this. Feel free to suggest something better!
Assuming this is acceptable though, my issue now is that while these animations are happening, I can't click any of the other controls on the UI. I get no response. It's not like it's just slow or delayed either - the click never comes through. It seems that the NSTimer processing totally locks the UI - but only from new interactions. Changes I make to the UI within the timer processing method happen just fine, and are very snappy.
From what I've read this shouldn't happen. However I also saw a comment on this question saying that if the timer processing is intensive then it could lock the UI thread. I don't see my processing to be that intensive here - certainly no resource requests, just a bit of data manipulating and animating some objects - but I could be underplaying it.
What are my options here? At first I thought I might create a new thread to kick off the timer. But I remember reading that the UI updates have to happen on the main thread anyway. Why is this? And plus, would that really solve the issue? Am I just asking too much of the device to process this timer as well as UI interactions? Is there something else I'm missing?
Any and all advice would be appreciated.
Edit:
I've just found the cause of my UI blocking problem. I was using the animateWithDuration with blocks, but was not setting the options. Therefore UIViewAnimationOptionAllowUserInteraction was not set. I changed it to set this option and my UI is happily responding now.
That said, I'll still leave this question open for specific suggestions regarding my overall approach. Thanks.
I would consider using CADisplayLink. From the documentation:
A CADisplayLink object is a timer object that allows your application to synchronize its drawing to the refresh rate of the display.
Your application creates a new display link, providing a target object and a selector to be called when the screen is updated. Next, your application adds the display link to a run loop.
Once the display link is associated with a run loop, the selector on the target is called when the screen’s contents need to be updated. The target can read the display link’s timestamp property to retrieve the time that the previous frame was displayed. For example, an application that displays movies might use the timestamp to calculate which video frame will be displayed next. An application that performs its own animations might use the timestamp to determine where and how displayed objects appear in the upcoming frame. The duration property provides the amount of time between frames. You can use this value in your application to calculate the frame rate of the display, the approximate time that the next frame will be displayed, and to adjust the drawing behavior so that the next frame is prepared in time to be displayed.
Your application can disable notifications by setting the paused property to YES. Also, if your application cannot provide frames in the time provided, you may want to choose a slower frame rate. An application with a slower but consistent frame rate appears smoother to the user than an application that skips frames. You can increase the time between frames (and decrease the apparent frame rate) by changing the frameInterval property.
When your application finishes with a display link, it should call invalidate to remove it from all run loops and to disassociate it from the target.
CADisplayLink should not be subclassed.
I'm not totally sure how everything is handled in your program, but you might want to just consider having one thread/timer that controls all of the objects and their movements. There's really no need to create a separate thread/timer for every single object, as that will easily cause problems.
You can just create a class for your moving items with some variables that contain information about their direction, speed, duration, etc, and then have a controlling thread/timer calculate and move the objects. You can then intervene onto the one main controller object instead of having to deal with many other objects.
I think you'll find that even if you optimize this, timer based animation like this is not going to perform well.
You might want to ask about the specific things that you think you couldn't do with CoreAnimation. If you solve those issues, you'll end up with a much better result than trying to roll your own.