FAQ Topic - How do I modify the content of the current page?(2010-04-14)
in [JavaScript]
|
Prev: test code with firefox 3.5.8 or better
Next: FAQ Topic - How can I see in javascript if a web browser accepts cookies? (2010-04-16)
From: Garrett Smith on 11 May 2010 03:22 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Stefan Weiss wrote: >>>> On 11/05/10 03:07, David Mark wrote: >>>>> Garrett Smith wrote: >>>>>> David Mark wrote: >>>>>>> Garrett Smith wrote: >> [...] >> >>>> I've noticed unexpected redraws in Opera in the past, when they didn't >>>> happen in other browsers on the same PC. Maybe Opera really does handle >>>> things differently here, or maybe all browsers do this, as you say, but >>>> with a different heuristic/logic behind the decision. >>> There's no telling exactly when any given browser will do it. >> No, they will repaint after alert, setTimeout, setInterval, etc. > > That only covers a small subset of possibilities. > Yes, but those are known cases. I know that with those cases, the browser will repaint. >> But they >>> won't do it at all unless you exit an execution context. >> Except when they do, such as with the example I provided a link to. I >> observed the behavior in a much older version of Mozilla on apple mac. > > Anything is possible. I didn't say that *every* browser ever made > behaved like this (just the hundreds I've dealt with over the years). > >> Doesn't really make much sense from an efficiency standpoint for the >> browser to repaint twice when it can repaint once so the fix makes >> sense. The browser not doing that anymore seems like a fix. > > Yes. It makes sense to queue changes until an execution context is > exited. Near as I can tell, that is what they do. It makes sense for the browser to not repaint until execution stack is complete and that is normally what they do. The odd cases are what I am interested in; where does the browser repaint other that that? Repainting flickers may be undesirable, but they're at least not failures. I have seen in many other cases Safari 2 and older mozilla not repainting and used the old window bounce trick (resizeBy(0, 1); resizeBy(0, -1), or scroll tricks, which will either fail or annoy the user. In some older mozillas (c 0.97) setting window.status would force a repaint. But that hack didn't last. Obviously throwing a random alert would be annoying to the user. I in fact have this very problem with the YUI test runner logger for Safari 2 in a few of my tests. I can see the results by resizing the window but for some reason the browser does not repaint. Anyway, it is senseless to design an API based on the possibility that browser might be more likely repaint if something is split and moved into a separate function. Unless of course there is a known case and it is avoidable and the code expresses that well enough. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 May 2010 03:26 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> Stefan Weiss wrote: >>>>> On 11/05/10 03:07, David Mark wrote: >>>>>> Garrett Smith wrote: >>>>>>> David Mark wrote: >>>>>>>> Garrett Smith wrote: >>> [...] >>> >>>>> I've noticed unexpected redraws in Opera in the past, when they didn't >>>>> happen in other browsers on the same PC. Maybe Opera really does >>>>> handle >>>>> things differently here, or maybe all browsers do this, as you say, >>>>> but >>>>> with a different heuristic/logic behind the decision. >>>> There's no telling exactly when any given browser will do it. >>> No, they will repaint after alert, setTimeout, setInterval, etc. >> >> That only covers a small subset of possibilities. >> > > Yes, but those are known cases. I know that with those cases, the > browser will repaint. > >>> But they >>>> won't do it at all unless you exit an execution context. >>> Except when they do, such as with the example I provided a link to. I >>> observed the behavior in a much older version of Mozilla on apple mac. >> >> Anything is possible. I didn't say that *every* browser ever made >> behaved like this (just the hundreds I've dealt with over the years). >> >>> Doesn't really make much sense from an efficiency standpoint for the >>> browser to repaint twice when it can repaint once so the fix makes >>> sense. The browser not doing that anymore seems like a fix. >> >> Yes. It makes sense to queue changes until an execution context is >> exited. Near as I can tell, that is what they do. > > It makes sense for the browser to not repaint until execution stack is > complete and that is normally what they do. No, that is your bad assumption. > The odd cases are what I am > interested in; where does the browser repaint other that that? For the fiftieth time, on exiting execution contexts with pending DOM changes (and when other unknown criteria are met). There's no way to pin them down exactly on that. Just avoid repaints (as well as reflows) in contexts where they can be destructive or wasteful. > > Repainting flickers may be undesirable, but they're at least not failures. Depends on your standards. If your goal is to create a "cool" effect, you can consider a flicker to be a failure (it sure as hell doesn't look cool). Not to mention that repaints can be _very_ expensive. It's a matter of performance as well as aesthetics. > > I have seen in many other cases Safari 2 and older mozilla not > repainting and used the old window bounce trick (resizeBy(0, 1); > resizeBy(0, -1), or scroll tricks, which will either fail or annoy the > user. In some older mozillas (c 0.97) setting window.status would force > a repaint. But that hack didn't last. Obviously throwing a random alert > would be annoying to the user. There are some odd cases where older browsers fail to repaint when they should. I haven't had to deal with that in some time. > > I in fact have this very problem with the YUI test runner logger for > Safari 2 in a few of my tests. I can see the results by resizing the > window but for some reason the browser does not repaint. It's a badly broken browser. > > Anyway, it is senseless to design an API based on the possibility that > browser might be more likely repaint if something is split and moved > into a separate function. Unless of course there is a known case and it > is avoidable and the code expresses that well enough. ISTM from your queries that you simply lack experience in this area. And it isn't always the case that you have to deal with the issue anyway. Context, context, context. ;) Hell, even in a comprehensive GP script like My Library, there is virtually nothing I would do differently, even if the issue did not exist.
From: Garrett Smith on 11 May 2010 17:47 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> Stefan Weiss wrote: >>>>>> On 11/05/10 03:07, David Mark wrote: >>>>>>> Garrett Smith wrote: >>>>>>>> David Mark wrote: >>>>>>>>> Garrett Smith wrote: [...] > ISTM from your queries that you simply lack experience in this area. I'm not asking. Nobody is. You posted a bad API design idea based on supposition and bullshit and I called you on it. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 May 2010 18:12 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> Garrett Smith wrote: >>>>> David Mark wrote: >>>>>> Stefan Weiss wrote: >>>>>>> On 11/05/10 03:07, David Mark wrote: >>>>>>>> Garrett Smith wrote: >>>>>>>>> David Mark wrote: >>>>>>>>>> Garrett Smith wrote: > > [...] > >> ISTM from your queries that you simply lack experience in this area. > > I'm not asking. Nobody is. You posted a bad API design idea based on > supposition and bullshit and I called you on it. How many times do you have to "call me" on such things to realize you invariably turn out to be wrong. It seems to happen every other month and then you feign amnesia. It's tiring.
From: Garrett Smith on 11 May 2010 23:50
David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> Garrett Smith wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: >>>>>> David Mark wrote: >>>>>>> Stefan Weiss wrote: >>>>>>>> On 11/05/10 03:07, David Mark wrote: >>>>>>>>> Garrett Smith wrote: >>>>>>>>>> David Mark wrote: >>>>>>>>>>> Garrett Smith wrote: >> [...] >> >>> ISTM from your queries that you simply lack experience in this area. >> I'm not asking. Nobody is. You posted a bad API design idea based on >> supposition and bullshit and I called you on it. > > How many times do you have to "call me" on such things to realize you > invariably turn out to be wrong. It seems to happen every other month > and then you feign amnesia. It's tiring. Sorry that was a bit inflammatory. AISI: The subject is "How do I modify the content of the current page". Stockton proposed promoting the code to function `Wryt`. You said that was not a good idea. I actually agree with that, but not for the reasons given; none of this has anything to do with repaints, animation, or your services. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |