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: Garrett Smith on 19 Jul 2010 15:32 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. -- Garrett
From: kangax on 19 Jul 2010 21:52 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> <https://developer.mozilla.org/en/Introduction_to_Layout_in_Mozilla> I would also like to (once again) quote Dave Hyat of WebKit fame (<www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/#comment-13157>): <quote> [...] element.style.width = �50px�; var v = element.offsetWidth; element.style.width = �55px�; v = element.offsetWidth; You just caused two reflows to happen, since asking for offsetWidth forced the element to reflow in order to answer you question (because it had a pending change to style). This is the real performance bottleneck to be wary of. Browsers are smart about avoiding reflows when they can, but if you create code that forces a reflow in order to answer a question, then you can create severe performance bottlenecks. [...] </quote> -- kangax
From: David Mark on 19 Jul 2010 22:33 On Jul 19, 9:52 pm, kangax <kan...(a)gmail.com> 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> > <https://developer.mozilla.org/en/Introduction_to_Layout_in_Mozilla> > > I would also like to (once again) quote Dave Hyat of WebKit fame > (<www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performa....>): > > <quote> > > [...] > > element.style.width = 50px; > var v = element.offsetWidth; > element.style.width = 55px; > v = element.offsetWidth; > > You just caused two reflows to happen, since asking for offsetWidth > forced the element to reflow in order to answer you question (because it > had a pending change to style). Of course, if the element is absolutely positioned, the browser won't have to re-flow the entire document. That's something else to keep in mind. > > This is the real performance bottleneck to be wary of. Browsers are > smart about avoiding reflows when they can, but if you create code that > forces a reflow in order to answer a question, then you can create > severe performance bottlenecks. > Yes and unnecessary repaints are even worse. Not just for performance, but they can wreak havoc on aesthetics as well.
From: Garrett Smith on 20 Jul 2010 01:04 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). > <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. > I would also like to (once again) quote Dave Hyat of WebKit fame > (<www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/#comment-13157>): > Nicole Sullivan's blog? I'll normall pass on that one. 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. So lets see what the OO-CSS expert has to say. | 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. var i; for(i = 0; i < 1000; i++) { moveDiv(); } function moveDiv(){ document.getElementById("a").style.left = i + "px"; repaint(); } function repaint() { // your code here. } Also do realize that when you flesh out the repaint, even if you can get it to work (it won't happen, but try if you like), then the fact that it works could not be used as argument that a repaint can be forced; it would only show that you did something and then a repaint occurred. > > > <quote> > > [...] > > element.style.width = �50px�; > var v = element.offsetWidth; > element.style.width = �55px�; > v = element.offsetWidth; > > You just caused two reflows to happen, since asking for offsetWidth > forced the element to reflow in order to answer you question (because it > had a pending change to style). > Does not state that reading `offsetWidth` will trigger a repaint? No, it doesn't. That's a good thing for Mr Hyatt because that would be a false statement. What it says is -- well it says exactly what it says, which is short and simple, so I won't try and paraphrase. And so reading offsetWidth to trigger a repaint would be a demonstration of a misconception that the consequences of doing that would cause a repaint (it won't). > This is the real performance bottleneck to be wary of. Browsers are > smart about avoiding reflows when they can, but if you create code that > forces a reflow in order to answer a question, then you can create > severe performance bottlenecks. > Informative, but not any evidence that a repaint can be triggered. -- Garrett
From: kangax on 20 Jul 2010 02:57
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-performance-making-your-javascript-slow/#comment-13157>): >> >> > > 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? > 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 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 you�ve written here applies to WebKit. There�s nothing overly scary about either a typical reflow or repaint in WebKit as long as what you do doesn�t 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. > > var i; > for(i = 0; i < 1000; i++) { > moveDiv(); > } > > function moveDiv(){ > document.getElementById("a").style.left = i + "px"; > repaint(); > } > > function repaint() { > // your code here. > } > > Also do realize that when you flesh out the repaint, even if you can get > it to work (it won't happen, but try if you like), then the fact that it > works could not be used as argument that a repaint can be forced; it > would only show that you did something and then a repaint occurred. Given lack of standard or definitive documentation, observations is the only thing we can work with. In Chrome your code does in fact trigger repaints every time style is queried (screenshot � <http://twitpic.com/26xr2n/full>). Look at multiple "layout" events, followed by "Style recalculation". That's what I meant by "observable ways to trigger reflow/repaint". > >> >> >> <quote> >> >> [...] >> >> element.style.width = �50px�; >> var v = element.offsetWidth; >> element.style.width = �55px�; >> v = element.offsetWidth; >> >> You just caused two reflows to happen, since asking for offsetWidth >> forced the element to reflow in order to answer you question (because it >> had a pending change to style). >> > > Does not state that reading `offsetWidth` will trigger a repaint? > > No, it doesn't. That's a good thing for Mr Hyatt because that would be a > false statement. > > What it says is -- well it says exactly what it says, which is short and > simple, so I won't try and paraphrase. > > And so reading offsetWidth to trigger a repaint would be a demonstration > of a misconception that the consequences of doing that would cause a > repaint (it won't). > >> This is the real performance bottleneck to be wary of. Browsers are >> smart about avoiding reflows when they can, but if you create code that >> forces a reflow in order to answer a question, then you can create >> severe performance bottlenecks. >> > Informative, but not any evidence that a repaint can be triggered. He said "...but if you create code that forces a reflow". As I read it, that means you _can_ create code that forces reflow. Why would he talk about something nonexistent? What exactly triggers reflow/repaint is a different story and probably varies among browsers. -- kangax |