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 20 Jul 2010 03:02 On 2010-07-19 01:28 AM, David Mark wrote: > On Jul 19, 3:37 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-18 08:26 PM, David Mark wrote:> On Jul 18, 10:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>> On 2010-07-18 02:42 PM, David Mark wrote: >> >>>>> On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> >>>>> [...] >> >>>>>> ext-touch-debug.js..............458k [...] > Where does this "native-first dual approach" term come from? I know > what you mean, but I've never heard it called that. I have named the query antipattern Native First Dual Approach, or "NFD approach". The NFD approach is to try to use `document.querySelectorAll`, where supported and where it is either unsupported or where it throws an error, a fallback selector matching engine is used. Libraries that use NFD include jQuery, YUI, and Ext-js, among others. Native-first Dual Approach Diagram (query input) | <Native QSA Support?> Y N | | | | [Try Use QSA] +-- [Use Fallback] | / | <error thrown?> / <Fallback Supports Input?> Y N-+ Y N | /| | [Throw error] | / | | | [Use Fallback*] | [perform match | | and return result] | | | | [return result] | | | | | END END END Diagram of native-first dual approach. Notice the three different possible endings. Most queries with attribute or pseudoclass selectors will have a different path depending on the browser, version, and rendering mode. Libraries that use NFD include jQuery, YUI, and Ext-js, among others. Dojo does the opposite. Dojo uses the fallback first and then, if that works, tries to use querySelectorAll. This might seem odd, but when the problems with NFD query engine is understood, it is much safer. Another approach is to filter all input by defining an `isValidQuery` type of function to make sure that it is valid. CSS Selectors are recursively defined: | selector | : simple_selector [ combinator selector | S+ [ combinator? selector | ]? ]? As such, it is not possible to parse one with a javascript RegExp because javascript RegExps are not recursive. The input must be parsed. Normative Reference: CSS2.1 <http://www.w3.org/TR/CSS2/grammar.html#grammar> >> >> Each bug in Ext-JS's selector engine necessarily propagates to a higher >> level. When the selector engine's behavior is changed, that change is >> propagated to all of the higher level dependencies. Such behavioral >> changes cause instability. The alternative to causing such changes is to >> not fix the bugs. > > I haven't bothered tracking down all of their problems as nobody has > offered me any money to do so. :) > [...] >> >>> Regardless, I'm sure that ExtJS fails to account for this (among many >>> other things). Just like jQuery! :) >> >>>> But that is about Ext-JS (big version), not Sencha. In Sencha, all of >>>> this stuff throws errors. >> >>> Of course as it has no query engine; it simply hands off all queries >>> to QSA. >> >> If it had simply handed queries off to `querySelectorAll`, it would not >> have created as many problems. > > Yes, I forgot about their inexplicable preprocessing. > It's like car with shoes for wheels. I could never forget that. >> >> Extra effort was required to split on "," and create a loop, adding >> duplicates to the returned result. > > Clearly tacked on my author(s) who had no idea what they were doing (a > common theme with these things). Who knows what they were thinking as > there are no explanatory comments. > There are from me. I explain exactly what the code does. I did not have to test it before making the analysis to know exactly how the code would perform and where it would fail. I was able to find the defects very quickly. >> >> The code with comments being blatantly false could be attributed to haste. > > For such a Frankenstein-like effort it probably is. Much of it sounds > like it is describing ExtJS. > Actually the current Ext-JS version does not support XPath. The code comment appears to be a hold-over from past jQuery copying efforts which had, in older versions of Ext, supported XPath. Regardless, to code comment is wrong. The code does not do what it says it does. >> >>>> | * E{display!=none} css value "display" that does not equal "none" >>>> | >>>> | >>>> | >>>> | This class is a singleton and cannot be created directly. >> >>> It's neither a class nor a singleton. >> It is a singleton in the sense that there is only one of them. >>>> | Public Properties >> >>> All JS properties are public. >> The various "privete" code comments are false claims. [...] >> >> Although library author is free to make any design decision he chooses, >> if the design decisions violate the CSS specifications and drafts (and >> these do), then the code cannot honestly be said to be CSS3 compliant. > > There's very little CSS3 in Sencha, despite the disingenuous ad > campaign. Not much HTML5 either. Who knew marketers lied? :) > The source code explains what it does. Those who are unable or unwilling to analyze the source code won't know. Fortunately that does not include me. The thread isn't as negative as some might see it. I showed that I can provide good code reviews that anyone at any level of experience -- the authors included -- should be able to appreciate. The review on the query engine provided a good model for making code review. I would like to encourage such reviews more. In addition to writing code, I provide assessments of code (in-house reviews) and mentor other developers. If the code is not awful -- and unfortunately most front end code is -- I can show how the code can be made to run twice as fast, on more devices, at less than half the size. >> >> Ext-JS claims "DomQuery supports most of the CSS3 selectors spec, along >> with some custom selectors and basic XPath". Whether Ext supports more >> than half of CSS3 selectors depends on the browser and the claim of >> "basic XPath" support is false (possibly outdated documentation from >> previous jQuery copying). > > Probably. > >> >>>> The `selectValue` and `selectNumber` methods are missing altogether from >>>> Sencha. >> >>> There's a lot of that going on. They were clearly pressed for time. >> The documentation does not reflect reality. >> >> The difference between marketing and engineering seems to not very well >> perceived. > > If at all. The first question on the mind of Web developers seems to > be about popularity. They seem to think that popularity implies > continuous improvement and easy support, despite overwhelming evidence > to the contrary (see jQuery). > Appeal to popularity. >> >> The number of individuals who look at the demos is going to be larger >> than the number of individuals who review the code. This is not surprising. > > Yes. What is surprising is that anyone would listen to "experts" who > advocate scripts based on pretty graphics and snazzy demos. > What else can they listen to? You think they want to come on usenet and read code reviews? And if they do, do you think they can understand your code reviews? Try and read the code review you wrote from the point of view of someone who is ignorant. My code review outline: <http://groups.google.com/group/comp.lang.javascript/msg/316e025b15e466a3?dmode=source> and follow-up: <http://groups.google.com/group/comp.lang.javascript/msg/c8f81b8b3486e3e8?dmode=source> Should those be linked from the the Code Guidelines doc and Code Review Guidelines docs? >> >> What is surprising is that prior to the recent angel investment into >> Sencha, they did not a few qualified individuals to do code review on >> it. > > The Ext people think they are qualified, though that misconception has > likely been shaken at this point (unless they are locked up in sound- > proof booths with blinders on). > What the Ext people think of themselves does not matter. "Is the salesman trying to make the product look good? Is there anything that he might not have told me, out of ignorance or otherwise?" >> This would not have been much investment and could have helped avoid >> such an amazing waste of money[1]. > > Yes. It's a shame to see people throwing good money after bad. > They seem misguided. >> >> From the perspective of the investor who does not have any idea of the >> code quality, he could employ two highly qualified individuals for a >> maximum of one week each to review and assess the code at a cost under >> 10,000 USD. > > Hell, I did it for free. Well, not really. I just touched on the > highlights here. I charged for the full analysis. Some people So they paid you? You wrote above that nobody offered you any money to do so. > realize that spending a little money to avoid wasting a lot makes good > business sense. It didn't take me a week and I didn't charge anywhere > near $5,000. But I could definitely write a similar (and much better) > framework in that neighborhood (and did so for one client about a year > back). > The investors may not have known that such an analysis was even possible. Can the source code be analyzed by an independent third party? Who knows? Returning to the car-purchasing example, a buyer might want to take the car he so likes (nice radio, comfy seats, looks cool, etc), down to his own mechanic for an analysis. Someone in the predicament of making assessments of the framework, but not having the skill to do so does not need a "mobile applications development framework shop"! What he needs is one or a few individuals who are qualified of making an assessment. Basically, what the investors needed was an expert analysis prior. The uninformed cannot know the least amount of time it will take to make such assessment. A very complicated framework that had good code and a sophisticated build process might take considerable time to and effort investigate and drawing metrics for it is going to be very involved and complicated. It turned out that such rigorous investigations would not have been necessary in this case because the code is so bad that it can be dismissed. Continued analysis beyond that point is pointless. What is the point in finding out how they've packaged and organized they're bugs? By accident, the `hasRightMarginBug` identifier was found to be absent and with the many false comments about properties being "private" (they aren't). >> >> Having volunteered so much free time over the years to spread knowledge >> of web development, it seems that too few care about the code. > > Oh, I bet somebody from Sencha is taking notes. The question is > whether they have anyone on the payroll who can interpret them in a > timely fashion. > I don't much care for giving free help to the Ext-JS guys. About 8 months ago, a colleage of mine informed me that they were in need of a JS developer. I re-familiarized myself with their code and found room for major improvement. And so I gave my colleage the "OK" to pass on my contact info. So, rather helping them, I get to do remote project postmortem, pro bono. [...] >> >> Any javascript developer who Ext-JS either has not read the source code >> enough, is not capable of understanding the problems, or has read and >> understood the problems but has not appreciated the consequences deeply. > > Happens all the time. > >> The choice to use Ext-JS is a substantially irresponsible and uninformed >> decision that puts quality and long-term success of his project at risk. > > And the choice to use Sencha Touch is exponentially worse, which could > only be described as insane. No, it could be described as misguided or not fully informed, or informed, but not understanding the ramifications. Do not consider "misguided" to be an insult; it is a position that most of us are in, in more ways than we realize. -- Garrett
From: David Mark on 20 Jul 2010 04:10 On Jul 20, 3:02 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-19 01:28 AM, David Mark wrote: > > > On Jul 19, 3:37 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >> On 2010-07-18 08:26 PM, David Mark wrote:> On Jul 18, 10:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>> On 2010-07-18 02:42 PM, David Mark wrote: > > >>>>> On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > > >>>>> [...] > > >>>>>> ext-touch-debug.js..............458k > > [...] > > > Where does this "native-first dual approach" term come from? I know > > what you mean, but I've never heard it called that. > > I have named the query antipattern Native First Dual Approach, or "NFD > approach". But who knows that? Using this abbreviation without explaining exactly what it means will likely lead to confusion. > > The NFD approach is to try to use `document.querySelectorAll`, where > supported and where it is either unsupported or where it throws an > error, a fallback selector matching engine is used. Yes. > > Libraries that use NFD include jQuery, YUI, and Ext-js, among others. > > Native-first Dual Approach Diagram > > (query input) > | > <Native QSA Support?> > Y N > | | > | | > [Try Use QSA] +-- [Use Fallback] > | / | > <error thrown?> / <Fallback Supports Input?> > Y N-+ Y N > | /| | [Throw error] > | / | | | > [Use Fallback*] | [perform match | > | and return result] | > | | | > [return result] | | > | | | > END END END > > Diagram of native-first dual approach. Notice the three different > possible endings. > > Most queries with attribute or pseudoclass selectors will have a > different path depending on the browser, version, and rendering mode. Yes. It's a completely insane design for a browser script. And the sad thing is that most jQuery scripts (including jQuery itself) rely on queries for everything. > > Libraries that use NFD include jQuery, YUI, and Ext-js, among others. Yes. > Dojo does the opposite. Dojo uses the fallback first and then, if that > works, tries to use querySelectorAll. Whatever. > This might seem odd, but when the > problems with NFD query engine is understood, it is much safer. I don't see how. Their fallback is complete BS. So what will it do when QSA contradicts it? > Another > approach is to filter all input by defining an `isValidQuery` type of > function to make sure that it is valid. Yes, that is the only 100% solution. Of course, most of the offending libraries needn't bother as they support very few browsers that lack QSA and will likely stop "supporting" the ones that don't (e.g. IE < 8) very soon. In the query department, they'll be reduced to wrappers for QSA and will then have more time to find other things to screw up. > > CSS Selectors are recursively defined: > > | selector > | : simple_selector [ combinator selector | S+ [ combinator? selector > | ]? ]? > > As such, it is not possible to parse one with a javascript RegExp > because javascript RegExps are not recursive. The input must be parsed. No question. That's what I did. > > Normative Reference: > CSS2.1 <http://www.w3.org/TR/CSS2/grammar.html#grammar> > > > > >> Each bug in Ext-JS's selector engine necessarily propagates to a higher > >> level. When the selector engine's behavior is changed, that change is > >> propagated to all of the higher level dependencies. Such behavioral > >> changes cause instability. The alternative to causing such changes is to > >> not fix the bugs. > > > I haven't bothered tracking down all of their problems as nobody has > > offered me any money to do so. :) > > [...] > > > > >>> Regardless, I'm sure that ExtJS fails to account for this (among many > >>> other things). Just like jQuery! :) > > >>>> But that is about Ext-JS (big version), not Sencha. In Sencha, all of > >>>> this stuff throws errors. > > >>> Of course as it has no query engine; it simply hands off all queries > >>> to QSA. > > >> If it had simply handed queries off to `querySelectorAll`, it would not > >> have created as many problems. > > > Yes, I forgot about their inexplicable preprocessing. > > It's like car with shoes for wheels. I could never forget that. I try not to retain every little screw-up I see in JS libraries. Thankfully I don't need to (unlike those who insist on relying on such things). > > > > >> Extra effort was required to split on "," and create a loop, adding > >> duplicates to the returned result. > > > Clearly tacked on my author(s) who had no idea what they were doing (a > > common theme with these things). Who knows what they were thinking as > > there are no explanatory comments. > > There are from me. I explain exactly what the code does. I know what the code does. I don't know what sort of thinking went into the authors' decision-making. There's no convenient explanation for such lunacy. > I did not have > to test it before making the analysis to know exactly how the code would > perform and where it would fail. Yes, seeing that code the first time was a spit-take moment for me as well. > > I was able to find the defects very quickly. Yes. It's amazing that virtually every line of code in the thing is defective. Like shooting fish in a barrel. Of course, the uninitiated can't fathom this, so I often hear the knee-jerk "wow you must have spent a lot of time on that" reaction. The reality is the authors' didn't spend near enough time. The fact that all of the "majors" are similarly defective leads to "aw, you just don't like frameworks" retorts. If you don't know any better, reviews are easy to misinterpret. > > > > >> The code with comments being blatantly false could be attributed to haste. > > > For such a Frankenstein-like effort it probably is. Much of it sounds > > like it is describing ExtJS. > > Actually the current Ext-JS version does not support XPath. I thought I saw it in there. Whatever. > The code > comment appears to be a hold-over from past jQuery copying efforts which > had, in older versions of Ext, supported XPath. > > Regardless, to code comment is wrong. The code does not do what it says > it does. Clearly. > > > > >>>> | * E{display!=none} css value "display" that does not equal "none" > >>>> | > >>>> | > >>>> | > >>>> | This class is a singleton and cannot be created directly. > > >>> It's neither a class nor a singleton. > > It is a singleton in the sense that there is only one of them. But that carries no weight in JS as there are only one of any object. There are no classes of objects, so there is no such differentiation to be made. > > >>>> | Public Properties > > >>> All JS properties are public. > > The various "privete" code comments are false claims. Yes. And they confuse the hell out of people. > > [...] > > > > >> Although library author is free to make any design decision he chooses, > >> if the design decisions violate the CSS specifications and drafts (and > >> these do), then the code cannot honestly be said to be CSS3 compliant. > > > There's very little CSS3 in Sencha, despite the disingenuous ad > > campaign. Not much HTML5 either. Who knew marketers lied? :) > > The source code explains what it does. Those who are unable or unwilling > to analyze the source code won't know. Fortunately that does not include > me. Unfortunately, those who would use something like this are unlikely to bother. Anyone who knows anything about this stuff would throw it away after reading the first line. > > The thread isn't as negative as some might see it. It's really hard to be positive about something so negative. That's another thing that the masses seem to misunderstand. These things really are incompetently done. There's no dancing around that fact. It's like they'd prefer to be lied to than to hear that truth. > I showed that I can > provide good code reviews that anyone at any level of experience -- the > authors included -- should be able to appreciate. I thought this was my review. Granted you chipped in a few bits. If they have any sense at all, the authors are taking notes. Of course, you can't really learn browser scripting from reading a review. There wasn't time to turn every point into a tutorial. > The review on the > query engine provided a good model for making code review. I would like > to encourage such reviews more. Then encourage them more. :) > > In addition to writing code, I provide assessments of code (in-house > reviews) and mentor other developers. Yes, I do as well. For those who want to learn (and actually save time rather than perpetually flushing it down the toilet). Most don't, apparently seeing Web development as some sort of puzzle that they need to solve on their own. > If the code is not awful -- and > unfortunately most front end code is -- I can show how the code can be > made to run twice as fast, on more devices, at less than half the size. I often find there's room for more dramatic improvement than that. I can remember a Dojo grid that took *minutes* to sort and I got that down to less than ten seconds. How? By eliminating unnecessary reflows/repaints. How did I do that? By eliminating function calls in between updating the cells. Of course, there was no guarantee that those reflows/repaints would occur on each call, but they clearly did often enough to decrease performance by roughly a factor of 10. I've made similar improvements in similar fashion to hundreds of functions. The rules don't seem to change, nor do the percentage of people who understand them (which is very small). > > > > >> Ext-JS claims "DomQuery supports most of the CSS3 selectors spec, along > >> with some custom selectors and basic XPath". Whether Ext supports more > >> than half of CSS3 selectors depends on the browser and the claim of > >> "basic XPath" support is false (possibly outdated documentation from > >> previous jQuery copying). > > > Probably. > > >>>> The `selectValue` and `selectNumber` methods are missing altogether from > >>>> Sencha. > > >>> There's a lot of that going on. They were clearly pressed for time.. > > The documentation does not reflect reality. Neither does the code. If only they did not reflect reality in the same way. :) > > > > >> The difference between marketing and engineering seems to not very well > >> perceived. > > > If at all. The first question on the mind of Web developers seems to > > be about popularity. They seem to think that popularity implies > > continuous improvement and easy support, despite overwhelming evidence > > to the contrary (see jQuery). > > Appeal to popularity. Yes. I find such appeals revolting. Programming is a science after all. And these scripts are 100% transparent. It's not like being stuck with a buggy OS (as some pseudo-intellectual observers like to compare them to). > > > > >> The number of individuals who look at the demos is going to be larger > >> than the number of individuals who review the code. This is not surprising. > > > Yes. What is surprising is that anyone would listen to "experts" who > > advocate scripts based on pretty graphics and snazzy demos. > > What else can they listen to? You think they want to come on usenet and > read code reviews? Some do, if only for the entertainment value. A few may actually learn something. The rest don't understand the words, so focus on the pervasive negativity, which makes them feel compassion for the bums that are trying to fleece them into using bogus scripts, buying worthless books, etc. > And if they do, do you think they can understand your > code reviews? There's nothing particularly subterranean about my reviews (particularly not this one). > Try and read the code review you wrote from the point of > view of someone who is ignorant. Well, if they don't know JS at all (which is a good bet as the authors of these scripts sure don't). > > My code review outline: > <http://groups.google.com/group/comp.lang.javascript/msg/316e025b15e46...> > > and follow-up: > <http://groups.google.com/group/comp.lang.javascript/msg/c8f81b8b3486e...> > > Should those be linked from the the Code Guidelines doc and Code Review > Guidelines docs? I don't understand the question. > > > > >> What is surprising is that prior to the recent angel investment into > >> Sencha, they did not a few qualified individuals to do code review on > >> it. > > > The Ext people think they are qualified, though that misconception has > > likely been shaken at this point (unless they are locked up in sound- > > proof booths with blinders on). > > What the Ext people think of themselves does not matter. The point is that they don't seek out qualified opinions as they think their own qualify as such (see Google, Yahoo, etc.) > > "Is the salesman trying to make the product look good? Is there anything > that he might not have told me, out of ignorance or otherwise?" Who are you quoting? > > >> This would not have been much investment and could have helped avoid > >> such an amazing waste of money[1]. > > > Yes. It's a shame to see people throwing good money after bad. > > They seem misguided. And lighter in the wallet. :) > > > > >> From the perspective of the investor who does not have any idea of the > >> code quality, he could employ two highly qualified individuals for a > >> maximum of one week each to review and assess the code at a cost under > >> 10,000 USD. > > > Hell, I did it for free. Well, not really. I just touched on the > > highlights here. I charged for the full analysis. Some people > > So they paid you? You wrote above that nobody offered you any money to > do so. Not Ext. I reviewed the whole thing from stem to stern for a client. And certainly Ext (er Sencha) has never been a client of mine. > > > realize that spending a little money to avoid wasting a lot makes good > > business sense. It didn't take me a week and I didn't charge anywhere > > near $5,000. But I could definitely write a similar (and much better) > > framework in that neighborhood (and did so for one client about a year > > back). > > The investors may not have known that such an analysis was even > possible. Can the source code be analyzed by an independent third party? > Who knows? I'm sure the investors didn't know anything about the source code. They were likely dazzled by the pretty graphics (which make up the bulk of the archive). > > Returning to the car-purchasing example, a buyer might want to take the > car he so likes (nice radio, comfy seats, looks cool, etc), down to his > own mechanic for an analysis. > > Someone in the predicament of making assessments of the framework, but > not having the skill to do so does not need a "mobile applications > development framework shop"! What he needs is one or a few individuals > who are qualified of making an assessment. > > Basically, what the investors needed was an expert analysis prior. Of course. And they clearly didn't get one. > > The uninformed cannot know the least amount of time it will take to make > such assessment. A very complicated framework that had good code and a > sophisticated build process might take considerable time to and effort > investigate and drawing metrics for it is going to be very involved and > complicated. > > It turned out that such rigorous investigations would not have been > necessary in this case because the code is so bad that it can be > dismissed. Continued analysis beyond that point is pointless. Like I said, I was pretty sure it was DOA on line 1. At least, that was a pretty strong indicator. By the time I got three or four dozen lines in, I was definitely sure. But I went ahead and read the rest. It was good for a laugh anyway. > > What is the point in finding out how they've packaged and organized > they're bugs? By accident, the `hasRightMarginBug` identifier was found > to be absent and with the many false comments about properties being > "private" (they aren't). You should read Dojo some day. Now there's a comedy classic. :) > > > > >> Having volunteered so much free time over the years to spread knowledge > >> of web development, it seems that too few care about the code. > > > Oh, I bet somebody from Sencha is taking notes. The question is > > whether they have anyone on the payroll who can interpret them in a > > timely fashion. > > I don't much care for giving free help to the Ext-JS guys. I don't either. That's why I don't solve *every* problem for them in the reviews (much to the chagrin of some anonymous posters). > About 8 > months ago, a colleage of mine informed me that they were in need of a > JS developer. They need more than one. > I re-familiarized myself with their code and found room > for major improvement. Yes, they've got plenty of vacancies. :) > > And so I gave my colleage the "OK" to pass on my contact info. So, > rather helping them, I get to do remote project postmortem, pro bono. There seems to be a scene missing. (?) > > [...] > > > > >> Any javascript developer who Ext-JS either has not read the source code > >> enough, is not capable of understanding the problems, or has read and > >> understood the problems but has not appreciated the consequences deeply. > > > Happens all the time. > > >> The choice to use Ext-JS is a substantially irresponsible and uninformed > >> decision that puts quality and long-term success of his project at risk. > > > And the choice to use Sencha Touch is exponentially worse, which could > > only be described as insane. > > No, it could be described as misguided or not fully informed, or > informed, but not understanding the ramifications. I meant in light of this thread. Obviously, if they haven't read it then they don't know. > > Do not consider "misguided" to be an insult I don't consider it an insult any more than misinformed or even ignorant. Of course some people are ignorant of the fact that ignorance is not the same as stupidity. > it is a position that most > of us are in, in more ways than we realize. Not me. I know exactly where I'm going. :)
From: Garrett Smith on 20 Jul 2010 04:24 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-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? > 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? >> >> 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. >> HEre is a complete example. 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. <!doctype html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>How do I make the browser repaint?</title> </head> <body> <div id="a" style="position: absolute; background: red; width: 20px; height: 20px; top: 4em; left: 0;">a</div> <script> function start(){ var i; for(i = 0; i < 1000; i++) { moveDiv(); } function moveDiv(){ document.getElementById("a").style.left = i + "px"; repaint(); } function repaint() { if(i === 500) { for(var j = 0; j < 5000; j++) { document.getElementById("a").innerHTML = "b"; document.title = new Date(j).toString(); } } // your code here. } } </script> <button onclick="start()">start()</button> </body> </html> > > 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>). > No, it does not. > Look at multiple "layout" events, followed by "Style recalculation". > That is style recalc. Remember recalc != repaint. > That's what I meant by "observable ways to trigger reflow/repaint". > You're conflating repaint and reflow now with punctuation. >> >>> >>> >>> <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? > Once again, does the quote from Hyatt state that reading `offsetWidth` will trigger a repaint? -- Garrett
From: kangax on 20 Jul 2010 09:24 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? > > 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. That much is clear. > > A repaint is when the browser paints the pixels so they are visually > rendered. Yep. [...] >>> | 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. > > 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. Ok. > > 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. [snip example] >> >> 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>). >> > > No, it does not. Sorry, it triggers reflow, not repaint (as you can see from the screeenshot). By reflow I mean what they call "layout" event (with description of "The browser's rendering engine performed layout calculations."). That's the only layout event displayed by SpeedTracer; there's no differentiation between reflow and "recalc" (as you call it). Repaint happens later, whenever browser finds time for it (as your example demonstrates). [...] >> 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? >> > > Once again, does the quote from Hyatt state that reading `offsetWidth` > will trigger a repaint? The quote implies that reading `offsetWidth` will trigger _reflow_ under certain conditions. I now see that there are 2 reasons for my misunderstanding of your argument. First of all, I didn't clearly differentiate reflow and repaint when you said "you can't force repaint". 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. -- kangax
From: David Mark on 20 Jul 2010 14:24
On Jul 20, 1:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> 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). > > > <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-performa....>): > > 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. > Browsers don't *always* reflow/repaint on exiting execution contexts. But the fact is that they do sometimes (I know this from experience). Nobody but the browser developers know exactly what factors determine whether they do it or not. 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. |