Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Sencha Touch--Support 2 browsers in just 228K!

Reply
Thread Tools

Sencha Touch--Support 2 browsers in just 228K!

 
 
Garrett Smith
Guest
Posts: n/a
 
      07-20-2010
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<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      07-20-2010
On 2010-07-19 01:28 AM, David Mark wrote:
> On Jul 19, 3:37 am, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-18 08:26 PM, David Mark wrote:> On Jul 18, 10:15 pm, Garrett Smith<(E-Mail Removed)> wrote:
>>>> On 2010-07-18 02:42 PM, David Mark wrote:

>>
>>>>> On Jul 18, 5:18 pm, Garrett Smith<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      07-20-2010
On Jul 20, 3:02*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-19 01:28 AM, David Mark wrote:
>
> > On Jul 19, 3:37 am, Garrett Smith<(E-Mail Removed)> *wrote:
> >> On 2010-07-18 08:26 PM, David Mark wrote:> *On Jul 18, 10:15 pm, Garrett Smith<(E-Mail Removed)> * *wrote:
> >>>> On 2010-07-18 02:42 PM, David Mark wrote:

>
> >>>>> On Jul 18, 5:18 pm, Garrett Smith<(E-Mail Removed)> * * *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 <
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 ofthe
> >> 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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-20-2010
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<(E-Mail Removed)> 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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-20-2010
On Jul 20, 1:04*am, Garrett Smith <(E-Mail Removed)> 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<(E-Mail Removed)> 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.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-20-2010
On Jul 20, 4:24*am, Garrett Smith <(E-Mail Removed)> 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<(E-Mail Removed)> 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 you’ve written here applies to WebKit.
> > There’s nothing overly scary about either a typical reflow or repaintin
> > 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.


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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-20-2010
On 2010-07-20 11:33 AM, David Mark wrote:
> On Jul 20, 4:24 am, Garrett Smith<(E-Mail Removed)> 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<(E-Mail Removed)> 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
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-20-2010
On Jul 20, 3:15*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-20 11:33 AM, David Mark wrote:
>
> > On Jul 20, 4:24 am, Garrett Smith<(E-Mail Removed)> *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<(E-Mail Removed)> *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.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-20-2010
On 2010-07-20 12:24 PM, David Mark wrote:
> On Jul 20, 3:15 pm, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-20 11:33 AM, David Mark wrote:
>>
>>> On Jul 20, 4:24 am, Garrett Smith<(E-Mail Removed)> 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<(E-Mail Removed)> 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
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      07-20-2010
On Jul 20, 8:24*pm, David Mark <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Not just different browsers that sites need testing in? Tim W HTML 11 08-08-2012 09:29 PM
Browsers, browsers! Quo vadis? El Kabong HTML 23 05-13-2007 08:55 PM
Is there something RoboForm that works for all programs, not just browsers? Jimmy Dean Computer Support 6 02-28-2006 04:20 AM
Two Browsers work! Two browsers won't load. Internet game service won't load jimmie Computer Support 1 02-26-2006 08:36 AM
allow you to move just about any music to your iPud, MP3 player , or just burn it to disk sbcmynews Computer Support 4 05-01-2005 03:53 PM



Advertisments