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: Ry Nohryb on 20 Jul 2010 18:22 On Jul 21, 12:10 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > 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. Oops, forgot to paste in the code: window.onload= function (here, stop, s) { here= document.getElementById('here'); s= 9; while (s < 4e2) { here.style.fontSize= ++s+ "px"; stop= +new Date()+ 50; while (+new Date() < stop) { ; } } here.style.fontSize= ""; setTimeout(onload, 1e3); }; -- Jorge.
From: David Mark on 20 Jul 2010 18:35 On Jul 20, 6:10 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > 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: No not only in Opera.
From: David Mark on 20 Jul 2010 18:44 On Jul 20, 6:06 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > 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. My, my what a jackass. Not only have I provided anecdotal evidence, which most assuredly happened (do you really think I would make up stories for you?), but I've provided at least one example that remains on the Web to this day. That was months ago, which is indicative of how ridiculous this "debate" has become. I was right. You were/are wrong. No amount of semantics will change that. > > > > >> Exhausting execution contexts -- sounds like they need to get some sleep. > > > That word has other meanings. > > Get some rest. Get some sense. > > > > >>>> 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 statement is (intentionally) vague. If you are saying that it won't do it on *every* function exit, then you have been agreeing with me all along. (?) > > Your sample demonstrates that at least one browser on > > Just one? Or most? Or was it every browser you tested in? I didn't test your code at all. But from experience I know that it likely won't repaint during the loop (which proves absolutely nothing). > > Which browser updated the position of the div at 500 and what else did > you do to get it to do that? You really think I bothered with your code? > > > 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"? Who are you quoting? > > >> 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? Again, your position has been that it *never* does it except when the execution stack is finished. That's false. The statement "it won't do it on exiting each function" can be interpreted two ways (that it will never do it on such exits and that it may well do it some of the time). Recall that the latter has been my assertion all along (and the former yours). > > > > >> 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". See above.
From: Garrett Smith on 20 Jul 2010 18:51 On 2010-07-20 06:24 AM, kangax wrote: > On 7/20/10 4:24 AM, Garrett Smith 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: > [...] >>>> 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? >> I still don't see that be taken as a personal attack on Nicole Sullivan. You quoted Dave Hyatt, the context in which the comment was made matters and so although normally I'd pass on reading that blog, it seemed only proper that the blog entry should be read so as to understand the context of Hyatt's context. So I'm not sure where I went wrong. Or if. [...] > >> >> 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. > > Right. > [...] > > Second � and more important � I have a different understanding of > "force/trigger"; I know that browsers don't _repaint_ on every change of > style (and/or querying of computed style after such change) but making > browser perform repaint in the near future falls under the definition of > "trigger repaint" for me. Browser doesn't repaint _immediately_ but it > still does eventually, which means that repaint was forced/triggered. > If there is new layout information that needs painting, the browser will hopefully paint it. The code in question may address an issue in webkit with repainting. Or it may address a problem that the authors have created. Method `Ext.Element.prototype.repaint` triggers an error condition by setting `dom.style.background = null`. That mistake is one of many mistakes. Think about reviewing some of this code. For example, you could look at `El.get` from ext-touch-debug-w-comments.js. I suggest (to anyone) to read it carefully, see what it does, what it gets wrong, and then test that. Then post up the findings. Just a reminder: Quick quips about the code are not helpful to anyone. I picked this function because there are things in it that I suspect you won't like. El.get = function(el){ var extEl, dom, id; if(!el){ return null; } if (typeof el == "string") { if (!(dom = document.getElementById(el))) { return null; } if (Ext.cache[el] && Ext.cache[el].el) { extEl = Ext.cache[el].el; extEl.dom = dom; } else { extEl = El.addToCache(new El(dom)); } return extEl; } else if (el.tagName) { if(!(id = el.id)){ id = Ext.id(el); } if (Ext.cache[id] && Ext.cache[id].el) { extEl = Ext.cache[id].el; extEl.dom = el; } else { extEl = El.addToCache(new El(el)); } return extEl; } else if (el instanceof El) { if(el != El.docEl){ el.dom = document.getElementById(el.id) || el.dom; } return el; } else if(el.isComposite) { return el; } else if(Ext.isArray(el)) { return El.select(el); } else if(el == document) { if(!El.docEl){ var F = function(){}; F.prototype = El.prototype; El.docEl = new F(); El.docEl.dom = document; } return El.docEl; } return null; }; -- Garrett
From: Garrett Smith on 20 Jul 2010 19:15
On 2010-07-20 03:44 PM, David Mark wrote: > On Jul 20, 6:06 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> 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. > > My, my what a jackass. > That's David Mark I know. And *that* is a example of ad hominem. More graceful ways to recognize a mistake than that exist. > Not only have I provided anecdotal evidence, which most assuredly > happened (do you really think I would make up stories for you?), but > I've provided at least one example that remains on the Web to this > day. That was months ago, which is indicative of how ridiculous this > "debate" has become. I was right. You were/are wrong. No amount of > semantics will change that. > I've stated nothing wrong. I've stated now four or five times that the browser won't repaint on exiting each function. You chose to argue about that. Why you would choose to argue about that can only be explained by you and so far you've not explained anything that supports why you believe the statement I made was incorrect. And while I cannot say your absense of an explanation is wrong, your claim that I was wrong is false and your claim that you have made an explanation was also not true. It's not the first time you've made such claims. Recall when I was copying everything you did, how I copied all of your best jQuery code reviews? How I was "aping" your code? The claim that my statement was false was incorrect. I can't see why you're having such trouble realizing it. Anyone who read it carefully and tested the example I posted should see that the statement I made is, in fact, correct and proven by my example. Is your ego getting in the way of recognizing the mistake? Pretty much anyone can recognize that what was posted was correct and continuing to say that it wasn't is unlikely to change that. Pity. Given what you've posted, I am afraid that the reader's judgment call may be to dismiss your review as that of a man who is not reasonable. >> >> >> >>>> Exhausting execution contexts -- sounds like they need to get some sleep. >> >>> That word has other meanings. >> >> Get some rest. > > Get some sense. > [...] >> >> Which browser updated the position of the div at 500 and what else did >> you do to get it to do that? > > You really think I bothered with your code? > I know that you tend to not read specs and don't test things very well. You tend to post carelessly and the formatting of the code reviews marks an example of 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"? > > Who are you quoting? > You brought up the subject of reasonable browser behavior but didn't say what that was. >> 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? > > Again, your position has been that it *never* does it except when the > execution stack is finished. OK. That's where you went wrong. I did not make that claim. -- Garrett |