Sencha Touch--Support 2 browsers in just 228K!
in [JavaScript]
|
Prev: FAQ Topic - What is JScript? (2010-07-16)
Next: How to find if statusbar is hidden or visible in firefox?
From: David Mark on 20 Jul 2010 14:33 On Jul 20, 4:24 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-19 11:57 PM, kangax wrote: > > > > > > > On 7/20/10 1:04 AM, Garrett Smith wrote: > >> On 2010-07-19 06:52 PM, kangax wrote: > >>> On 7/19/10 3:32 PM, Garrett Smith wrote: > >>>> On 2010-07-19 12:29 AM, Ry Nohryb wrote: > >>>>> On Jul 19, 9:04 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: > >>>>>> (...) > > >>>>>>> For example, this (google groups) page can be forced to repaint > >>>>>>> with: > > >>>>>> No, it cannot. About the best you can do is hope that the browser > >>>>>> will > >>>>>> repaint. > > >>>>>> So you've made observations of what happened in the browser and > >>>>>> concluded that those observations are premises for causality, huh? > >>>>>> (...) > > >>>>> What I said is not based on any "mystical incantation" but on what the > >>>>> author of Mozilla's rendering engine explains in this video: > > >>>>> "Faster HTML and CSS: Layout Engine Internals for Web Developers", > >>>>> David Baron. > >>>>>http://www.youtube.com/v/a2_6bGNZ7bA > > >>>>> Obviously you too (I told Mark already) ought to see it in order to > >>>>> learn the fundamentals of the inner workings of rendering engines, and > >>>>> once you begin to see through the black box, you (and Mark) will be > >>>>> able to stop thinking about it any more in terms of mystical > >>>>> incantations. > > >>>> That's not a standard and not any browser documentation. It does not > >>>> explain how to force a repaint. I find it painful to watch that man > >>>> speak. Is there particular citation that you would like to reference? > >>>> You can enter the text. > > >>> What he talks about is also partially present in these documents (by > >>> same author): > > >>> <https://developer.mozilla.org/en/Notes_on_HTML_Reflow> > > >> That document discusses reflow (in Gecko). > > > Yes. You mentioned browser documentation. That's the one I'm aware of, > > and it's related to the topic discussed here. > > >>> <https://developer.mozilla.org/en/Introduction_to_Layout_in_Mozilla> > > >> That document discusses painting (in Gecko) and states the event that > >> triggers it as being content received. It does not state which mechanism > >> is responsible for triggering repainting. > > > But the previous one does, afaict (although vaguely). > > > "A style change reflow is performed when the presentation shell's global > > stylistic information is changed; e.g., addition or removal of a style > > sheet, a change to the shell's default font." > > >>> I would also like to (once again) quote Dave Hyat of WebKit fame > >>> (<www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performa...>): > > >> Nicole Sullivan's blog? I'll normall pass on that one. > > > What's with ad hominem? :) I'm failing to see how it matters on which > > blog WebKit developer explains when/how reflow occurs in WebKit? > > What ad hominem? Are you reading more into what I wrote? > > What you seem to fail to grasp is that recalc != repaint. That is, > recalc is not causing pixels to be visully updated to the user. > > A repaint is when the browser paints the pixels so they are visually > rendered. > > >> It seems you've > >> got a disagreement with the fact that there's no way to force the > >> browser to repaint, but you won't actually say that and just post up > >> links. > > > Wait, didn't I start original reply with "There certainly are observable > > ways to trigger ..."? Is that "not actually saying it"? > > So you think you can force a repaint, huh? > > It didn't actually happen in the loop test, though, did it? That doesn't mean that it won't do it in all cases. The browser knows it is in a loop after all. > > > > > > >> So lets see what the OO-CSS expert has to say. > > > I linked to Hyat's comment though, not post itself. He even says that > > most of what she says doesn't apply to WebKit in an earlier comment: > > > <quote> > > Just FYI, very little of what youve written here applies to WebKit. > > Theres nothing overly scary about either a typical reflow or repaint in > > WebKit as long as what you do doesnt affect the geometry of the entire > > page. > > </quote> > > >> | A repaint occurs when changes are made to an elements skin that > >> } changes visibility, but do not affect its layout > > >> The repaint may occur after a request for a style change has been made, > >> but that won't happen every time. > > >> Try writing a loop-based animation and if you can get it to update, then > >> you've gotten a repaint to occur. > > HEre is a complete example. Another loop. You can can't force a repaint, but you can't predict when they will happen either (your theory about waiting until the execution stack is exhausted is definitely wrong). > > Notice that when the div gets to "500" that the title will update in > chrome. You may want to bump the j loop up to 50000 iterations -- 10x > what it is now (5000) to notice that. > > The div starts at the left and ends 1000px left from that. It is not > ever visibile at 500. Setting innerHTML didn't change that; nothing > will. You can't make the browser repaint. > > The best you can do is give it a condition under which it thinks a > repaint should occur and then wait for it to do that. It won't do it on > exiting each function but it should probably want to do that after > completing the stack of execution contexts. Your general "it won't do it on exiting each function" statement is just as false as saying it will do it on demand. The fact is that browsers do sometimes reflow/repaint on exiting execution contexts (and before the stack is exhausted). It would certainly be nice if they didn't, but I know from experience that is not the case. For one, I can't count how many times I've improved the performance of widgets by avoiding function calls in the middle of updating styles. And I mean exponentially, so it wasn't just the overhead of calling the functions. For two, I've dealt with flickers and twitches due to "unexpected" repaints. They happen in some contexts and the solution is always the same.
From: Garrett Smith on 20 Jul 2010 15:15 On 2010-07-20 11:33 AM, David Mark wrote: > On Jul 20, 4:24 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-19 11:57 PM, kangax wrote: >> >> >> >> >> >>> On 7/20/10 1:04 AM, Garrett Smith wrote: >>>> On 2010-07-19 06:52 PM, kangax wrote: >>>>> On 7/19/10 3:32 PM, Garrett Smith wrote: >>>>>> On 2010-07-19 12:29 AM, Ry Nohryb wrote: >>>>>>> On Jul 19, 9:04 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: >>>>>>>> (...) >> [snip massive overquote] >> HEre is a complete example. > > Another loop. You can can't force a repaint, but you can't predict > when they will happen either (your theory about waiting until the > execution stack is exhausted is definitely wrong) > What's wrong and why? Exhausting execution contexts -- sounds like they need to get some sleep. >> >> Notice that when the div gets to "500" that the title will update in >> chrome. You may want to bump the j loop up to 50000 iterations -- 10x >> what it is now (5000) to notice that. >> >> The div starts at the left and ends 1000px left from that. It is not >> ever visibile at 500. Setting innerHTML didn't change that; nothing >> will. You can't make the browser repaint. >> >> The best you can do is give it a condition under which it thinks a >> repaint should occur and then wait for it to do that. It won't do it on >> exiting each function but it should probably want to do that after >> completing the stack of execution contexts. > > Your general "it won't do it on exiting each function" statement is > just as false as saying it will do it on demand. The fact is that No, that statement is correct and the xample shows that to be true. tt render the div -- no repainting. Function `moveDiv` calls `document.getElementById` and `repaint` each 1000x. Function repaint calls the `Date` constructor and `Date.prototype.toString` 5000x each. That makes 11000 function calls, if I counted right. All that is needed to determine that the browser will not repaint on exiting each function call is to find one case where exiting a function call does not cause a repaint. The example fulfills that requirement. No repainting took place after any of some 11000 function calls. -- Garrett
From: David Mark on 20 Jul 2010 15:24 On Jul 20, 3:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-20 11:33 AM, David Mark wrote: > > > On Jul 20, 4:24 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >> On 2010-07-19 11:57 PM, kangax wrote: > > >>> On 7/20/10 1:04 AM, Garrett Smith wrote: > >>>> On 2010-07-19 06:52 PM, kangax wrote: > >>>>> On 7/19/10 3:32 PM, Garrett Smith wrote: > >>>>>> On 2010-07-19 12:29 AM, Ry Nohryb wrote: > >>>>>>> On Jul 19, 9:04 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: > >>>>>>>> (...) > > [snip massive overquote] > > >> HEre is a complete example. > > > Another loop. You can can't force a repaint, but you can't predict > > when they will happen either (your theory about waiting until the > > execution stack is exhausted is definitely wrong) > > What's wrong and why? I explained that. In short, it's false. > > Exhausting execution contexts -- sounds like they need to get some sleep. That word has other meanings. > > > > > > > > >> Notice that when the div gets to "500" that the title will update in > >> chrome. You may want to bump the j loop up to 50000 iterations -- 10x > >> what it is now (5000) to notice that. > > >> The div starts at the left and ends 1000px left from that. It is not > >> ever visibile at 500. Setting innerHTML didn't change that; nothing > >> will. You can't make the browser repaint. > > >> The best you can do is give it a condition under which it thinks a > >> repaint should occur and then wait for it to do that. It won't do it on > >> exiting each function but it should probably want to do that after > >> completing the stack of execution contexts. > > > Your general "it won't do it on exiting each function" statement is > > just as false as saying it will do it on demand. The fact is that > > No, that statement is correct and the xample shows that to be true. No it doesn't. Your sample demonstrates that at least one browser on one PC failed to do it in a loop. I find it quite reasonable that browsers would abstain from repaints in such a loop. Don't you? > tt render the div -- no repainting. Function `moveDiv` calls > `document.getElementById` and `repaint` each 1000x. Function repaint > calls the `Date` constructor and `Date.prototype.toString` 5000x each. > That makes 11000 function calls, if I counted right. > > All that is needed to determine that the browser will not repaint on > exiting each function call is to find one case where exiting a function > call does not cause a repaint. As I've said (about 1000 times now, dating back for years). They don't *always* do it. The key word is *always*. So your loop does not disprove my position. > > The example fulfills that requirement. No repainting took place after > any of some 11000 function calls. And likely won't after 11 million function calls. All you have demonstrated is one case where a browser does not repaint.
From: Garrett Smith on 20 Jul 2010 18:06 On 2010-07-20 12:24 PM, David Mark wrote: > On Jul 20, 3:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-20 11:33 AM, David Mark wrote: >> >>> On Jul 20, 4:24 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>> On 2010-07-19 11:57 PM, kangax wrote: >> >>>>> On 7/20/10 1:04 AM, Garrett Smith wrote: >>>>>> On 2010-07-19 06:52 PM, kangax wrote: >>>>>>> On 7/19/10 3:32 PM, Garrett Smith wrote: >>>>>>>> On 2010-07-19 12:29 AM, Ry Nohryb wrote: >>>>>>>>> On Jul 19, 9:04 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: >>>>>>>>>> (...) >> >> [snip massive overquote] >> >>>> HEre is a complete example. >> >>> Another loop. You can can't force a repaint, but you can't predict >>> when they will happen either (your theory about waiting until the >>> execution stack is exhausted is definitely wrong) >> >> What's wrong and why? > > I explained that. In short, it's false. > Here you go again with "I've already explained" stories, claiming to have done things that never took place. My my what an imagination. >> >> Exhausting execution contexts -- sounds like they need to get some sleep. > > That word has other meanings. > Get some rest. >>>> Notice that when the div gets to "500" that the title will update in >>>> chrome. You may want to bump the j loop up to 50000 iterations -- 10x >>>> what it is now (5000) to notice that. >> >>>> The div starts at the left and ends 1000px left from that. It is not >>>> ever visibile at 500. Setting innerHTML didn't change that; nothing >>>> will. You can't make the browser repaint. >> >>>> The best you can do is give it a condition under which it thinks a >>>> repaint should occur and then wait for it to do that. It won't do it on >>>> exiting each function but it should probably want to do that after >>>> completing the stack of execution contexts. >> >>> Your general "it won't do it on exiting each function" statement is >>> just as false as saying it will do it on demand. The fact is that >> >> No, that statement is correct and the xample shows that to be true. > > No it doesn't. The example shows a function call completing and a repaint no occurring and so "it won't do it on exiting each function" is a true statement. Your sample demonstrates that at least one browser on Just one? Or most? Or was it every browser you tested in? Which browser updated the position of the div at 500 and what else did you do to get it to do that? > one PC failed to do it in a loop. I find it quite reasonable that > browsers would abstain from repaints in such a loop. Don't you? > What "reasonable browser behavior"? >> tt render the div -- no repainting. Function `moveDiv` calls >> `document.getElementById` and `repaint` each 1000x. Function repaint >> calls the `Date` constructor and `Date.prototype.toString` 5000x each. >> That makes 11000 function calls, if I counted right. >> >> All that is needed to determine that the browser will not repaint on >> exiting each function call is to find one case where exiting a function >> call does not cause a repaint. > > As I've said (about 1000 times now, dating back for years). They > don't *always* do it. The key word is *always*. So your loop does > not disprove my position. > The example proves "it won't do it on exiting each function", which you claimed to be false and *that* claim was a false claim. Have you been sleeping? >> >> The example fulfills that requirement. No repainting took place after >> any of some 11000 function calls. > > And likely won't after 11 million function calls. All you have > demonstrated is one case where a browser does not repaint. That was all that was needed to suppor the claim "it won't do it on exiting each function". -- Garrett
From: Ry Nohryb on 20 Jul 2010 18:10
On Jul 20, 8:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > (...) The above example likely illustrates that > they abstain while in the middle of a loop. > > The important thing to know is that they do *not* repaint until they > exit the context that queued the style changes. You can't force > repaints on demand, but can certainly avoid them when needed. > (...) Except Opera. Oper repaints in a separate thread, in parallel with the JS thread: http://jorgechamorro.com/cljs/101/ Only in Opera: you'll see a growing green dot dropping. Tested in : navigator.userAgent: Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.6.30 Version/10.60. -- Jorge. |