what does Recalculate Layout Paint mean in chrome developer tool TimeLine records? and how to improve the page performance by reduce the page Recalculate,Layout and Paint's count? can give some suggestion?thanks
Basically, they're your browser figuring out how to draw the changes that you made to the page.
Don't worry about getting rid of them -- if you did that, your site would be static.
However... ...if you want to do something that IS useful for performance, which does have to do with reflows and repaints, then batch your changes together.
Lets say that you got a job at Twitter.
And your job is to write the next version of the window that adds each twitter post to the screen.
If a user gets 250 new tweets in their timeline, and you add each one in a loop, one after the other, the browser is going to slow way down, because every time you add one, it will have to reflow (move things around to make space for the thing you added) and repaint (style everything that was affected by the addition).
A better way of doing it would be to build the list of new tweets together off-DOM (ie: with elements that aren't actually on the page right now), and then add them all at once.
This cuts down on the number of times that a browser has to figure out where everything needs to go.
#Fabricio -- Micro-optimizing might not be great, but appending hundreds of browser elements in a loop, versus putting all of them in at the same time can make a big difference.
Just ask the Twitter guys, who weren't bothering to cache their jQuery objects.
Here's a very handy list of properties and methods that trigger the layout (reflow) of a page:
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
You want to minimize these calls as much as possible -- especially in situations where performance is critical, such as during the scroll event, or when animating large blocks of content.
You can use the "Profiles" tab and "Audits" tab to detect the performance of your code. The will give you a report about your codes.
You can reduce the page Recalculate,Layout and Paint's count by many ways.
Append many child at one time.
Hide elements before change them.
Give images and other elements height and width.
Related
I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.
when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.
I was wondering if, whenever I have a situation in which I have to hide some UI element temporarily, it is sufficient to hide it (many frameworks give this option) or I should delete the object in memory and recreate it later when needed again (with the same parameters).
What are the pros and cons of each solution? I was thinking that maybe by hiding the element you save state informations that may be important, and you also save the allocation time, so maybe it is the better way for elements that must be hidden for a short period of time. But what if the time becomes bigger? I would then have a non-needed object in memory for the whole time.
One example, to give a clear picture of what I am talking about, would be a toolbar that changes buttons based on some context change. That is, normally there are some buttons attached to the toolbar, but when the user select one action in some other part of the interface, those buttons must be replaced by new ones (one of which is the "Done" button). Similarly, when the user selects the "Done" button in the toolbar, it goes back to the initial state.
I don't know if this is a stupid question and maybe it could be that I'm doing something like premature optimization... but I will be thankful for all your answers.
I think that the general rule of the thumb is that elements that you plan to reshow, should be hidden; otherwise destroyed (some exceptions obviously apply). When/if this becomes infeasible, you could consider further optimizations.
It's a very good question. Here's what occurs to me:
Suppose (just for the sake of argument) you have lots of different forms that could be displayed in the same space. Then if you create/destroy controls, you are only paying at any one time for the controls that the user can see. On the other hand, if you hide/show controls, you are paying all the time for the large number of controls the user isn't looking at (and may never look at). So I always create/destroy. (Actually I keep previously used controls in pools so I'm not actually re-creating them.)
Many people store user state in the controls of the UI, but personally I hate that and I never do it. I think if some information is worth remembering it belongs in application data structure. This means of course, that the controls of the current visible form have to be "bound" or kept current with the application data structure. I just make sure I can do that no matter what.
I've had to be inventive to accomplish these in a way that simplifies application code, and as a result the method I use is not well known, which exacts another kind of price.
There is no general answer to this question. It depends on the system type, CPU and RAM restrictions, the number of UI elements in question, how frequently the UI is going to be shown / recreated, etc. Perhaps if you could give an example we might be able to give you more concise feedback.
Javascript objects are not like Windows (GDI) objects: they usually don't have a will to send/receive messages - almost passive. It takes less code to hide, right?
Perhaps it depends on total amount of interactive objects per user session.
What are there the usability implications for a long list of items (f.e. facebook news stream) to use an internal scrolling (just the list panel) vs a full page scrolling.
Edit1: Do you have references of analysis/guidelines discussing this issue?
Depends on the composition of the page.
If the page displays other information and it is desired to keep an eye on it while scrolling that long list, then it may be preferable to use what you call "internal scrolling".
On the other hand, such scrollable parts are generally considered to be signs of a bad UI design. If you bring the argument that without scrolls the page would become huge, then you may want to reconsider the page layout and what information is really needed here together. Splitting a page into multiple specific views without scrolls might be a better idea.
From my experience multiple scrollbars on a page frustrate users, The best thing you can do is use CSS/javascript/jQuery to make items that you want to stay on the page move with the user. Slashdot's commenting system uses something similar to keep information pinned to the top of the page where it's needed. There's lots of other examples on the web, and it generally leaves a good impresssion on the user.
I'm trying to modify Brian Reindel's Accessible News Slider plugin (sorry, it won't let me link to it and also to my work location), to allow a visitor to fill in multiple copies of a form, sliding back and forth between them. I need for the visitor to be able to add and delete copies of the form from the list. I've modified one of his examples and created a little function to add an element to the list. However, no matter how many times I call the function, it only adds one element, and the plugin is not aware of it; I can see it in the DOM Inspector, but that's it. What am I missing?
this is Brian. Since you're already using jQuery and the plugin, you would gain a great deal by using the library to append elements to the DOM within your custom function. I wanted to give you some guidance, since this is probably more work than you were inititally expecting. Here are some hopefully helpful tips:
The plugin calculates some wrapper
element widths based upon the number
of list items. If you add/remove list
items, then you would need to modify
the calculations that were made or
else it won't scroll properly. You'll probably experience the same types of issues for the click events on the next/previous buttons.
If you have events registered on
elements that you add/remove from the
DOM, then you will need to
re-register those events, since when
the elements are gone, so are the
events that were "bound" to them. It
doesn't look like this is your
problem though at this point.
If you're adding form elements to the
DOM on the fly using the "Add" link,
then the user's cursor focus is no
longer on the form elements, and the
slider is no longer really
accessible. As much as I love
plugging my own plugin, it was meant
mostly to demonstrate usable, custom styled accessible
JavaScript, and I'm not sure it is
flexible enough to do what you want
without some rework.
If you have more specific questions about how to do certain things to get you started on the right track, let me know, and I would be happy to help. Depending on how much you plan to use jQuery on your projects (and I highly recommend that you use it), try out the book Learning jQuery.