Event wanted after page is refreshed

Discussion in 'Javascript' started by Stefan Mueller, Dec 26, 2009.

  1. I've a html table which is sortable by clicking on the header of each
    column.
    Because the sorting sometimes takes a couple of seconds I'd like to
    prevent that the user can click the header of a column while the sort
    function is running.

    Here's my approach:
    I do at the end of the sort function
    sort_end_time = new Date().getTime();
    and at the beginning of the sort function I check how much time has
    passed after the sort function finished last time
    if ((new Date().getTime() - sort_end_time) > 300) {

    In this example you have to wait 300 milliseconds before you can sort
    the next column. Therefore if you click on a column before the running
    sort function has finished doing its job the value of '(new Date
    ().getTime() - sort_end_time)' is less than 300 milliseconds and the
    clicked column will not get sorted. The problem I have now is that
    when the last javascript command 'sort_end_time = new Date().getTime
    ();' is executed the browser needs some time to redraw (refresh) the
    table on the screen. If the table has only a couple of rows then it
    takes only some milliseconds but if the table has e.g. 2000 rows it
    takes in IE more than 1000 milliseconds. Therefore the result of '(new
    Date().getTime() - sort_end_time)' is always greater than 300
    milliseconds.

    Is there any possibility, any event where I can execute the command
    'sort_end_time = new Date().getTime();' just after the browser is
    ready again (after the refresh)? In my case the command 'sort_end_time
    = new Date().getTime();' (the last command of the sort function) is
    executed before the browser starts the redraw (refresh).

    Stefan
     
    Stefan Mueller, Dec 26, 2009
    #1
    1. Advertising

  2. Stefan Mueller

    JR Guest

    On 26 dez, 17:58, Stefan Mueller <> wrote:
    > I've a html table which is sortable by clicking on the header of each
    > column.
    > Because the sorting sometimes takes a couple of seconds I'd like to
    > prevent that the user can click the header of a column while the sort
    > function is running.


    This kind of sorting shouldn't take longer than a few milliseconds.
    Maybe the code is not optimized for the browser in which you're
    testing it.

    > Here's my approach:
    > I do at the end of the sort function
    >   sort_end_time = new Date().getTime();
    > and at the beginning of the sort function I check how much time has
    > passed after the sort function finished last time
    >   if ((new Date().getTime() - sort_end_time) > 300) {
    >
    > In this example you have to wait 300 milliseconds before you can sort
    > the next column. Therefore if you click on a column before the running
    > sort function has finished doing its job the value of '(new Date
    > ().getTime() - sort_end_time)' is less than 300 milliseconds and the
    > clicked column will not get sorted. The problem I have now is that
    > when the last javascript command 'sort_end_time = new Date().getTime
    > ();' is executed the browser needs some time to redraw (refresh) the
    > table on the screen. If the table has only a couple of rows then it
    > takes only some milliseconds but if the table has e.g. 2000 rows it
    > takes in IE more than 1000 milliseconds. Therefore the result of '(new
    > Date().getTime() - sort_end_time)' is always greater than 300
    > milliseconds.
    >
    > Is there any possibility, any event  where I can execute the command
    > 'sort_end_time = new Date().getTime();' just after the browser is
    > ready again (after the refresh)? In my case the command 'sort_end_time
    > = new Date().getTime();' (the last command of the sort function) is
    > executed before the browser starts the redraw (refresh).


    You can prevent a code from being called twice using the
    'arguments.callee.done' old trick, e.g.:

    function sort() {
    if (!arguments.callee.done) { // checks the 'done' property of sort
    ().
    return; // exit.
    }
    // If code doesn't return, do the sort stuff hereafter.
    // But in the end of the sorting, don't forget to set
    // arguments.callee.done = true;
    }

    Cheers,
    JR
     
    JR, Dec 27, 2009
    #2
    1. Advertising

  3. Stefan Mueller

    JR Guest

    On 27 dez, 11:27, JR <> wrote:
    > On 26 dez, 17:58, Stefan Mueller <> wrote:
    >
    > > I've a html table which is sortable by clicking on the header of each
    > > column.
    > > Because the sorting sometimes takes a couple of seconds I'd like to
    > > prevent that the user can click the header of a column while the sort
    > > function is running.

    >
    > This kind of sorting shouldn't take longer than a few milliseconds.
    > Maybe the code is not optimized for the browser in which you're
    > testing it.
    >
    >
    >
    > > Here's my approach:
    > > I do at the end of the sort function
    > >   sort_end_time = new Date().getTime();
    > > and at the beginning of the sort function I check how much time has
    > > passed after the sort function finished last time
    > >   if ((new Date().getTime() - sort_end_time) > 300) {

    >
    > > In this example you have to wait 300 milliseconds before you can sort
    > > the next column. Therefore if you click on a column before the running
    > > sort function has finished doing its job the value of '(new Date
    > > ().getTime() - sort_end_time)' is less than 300 milliseconds and the
    > > clicked column will not get sorted. The problem I have now is that
    > > when the last javascript command 'sort_end_time = new Date().getTime
    > > ();' is executed the browser needs some time to redraw (refresh) the
    > > table on the screen. If the table has only a couple of rows then it
    > > takes only some milliseconds but if the table has e.g. 2000 rows it
    > > takes in IE more than 1000 milliseconds. Therefore the result of '(new
    > > Date().getTime() - sort_end_time)' is always greater than 300
    > > milliseconds.

    >
    > > Is there any possibility, any event  where I can execute the command
    > > 'sort_end_time = new Date().getTime();' just after the browser is
    > > ready again (after the refresh)? In my case the command 'sort_end_time
    > > = new Date().getTime();' (the last command of the sort function) is
    > > executed before the browser starts the redraw (refresh).

    >
    > You can prevent a code from being called twice using the
    > 'arguments.callee.done' old trick, e.g.:
    >
    > function sort() {
    >   if (!arguments.callee.done) { // checks the 'done' property of sort
    > ().
    >     return; // exit.
    >   }
    >   // If code doesn't return, do the sort stuff hereafter.
    >   // But in the end of the sorting, don't forget to set
    >   // arguments.callee.done = true;
    >
    > }
    >
    > Cheers,
    > JR


    Sorry, the correct sequence goes below:

    function sort() {
    if (arguments.callee.done) return;
    arguments.callee.done = true;
    // do the sort stuff.
    arguments.callee.done = false; // in the end.
    }

    --
    JR
     
    JR, Dec 27, 2009
    #3
  4. Stefan Mueller

    David Mark Guest

    On Dec 27, 5:11 am, Hans-Georg Michna <hans-
    > wrote:
    > On Sat, 26 Dec 2009 11:58:43 -0800 (PST), Stefan Mueller wrote:
    > >Is there any possibility, any event  where I can execute the command
    > >'sort_end_time = new Date().getTime();' just after the browser is
    > >ready again (after the refresh)? In my case the command 'sort_end_time
    > >= new Date().getTime();' (the last command of the sort function) is
    > >executed before the browser starts the redraw (refresh).

    >
    > Stefan,
    >
    > checkhttp://winhlp.com/node/633for some basic thoughts about
    > the rendering to screen and its detection.
    >
    > But you may be trying to kill a non-existent dragon. JavaScript
    > execution is single-threaded. No second JavaScript thread can
    > start before the current one has finished.
    >
    > Most browsers don't even render to screen, as long as any
    > JavaScript task is running, with the exception of Opera.
    >


    They all work about the same in that regard. They can re-flow on
    exiting execution contexts.
     
    David Mark, Dec 27, 2009
    #4
  5. In comp.lang.javascript message <2b8192d5-88aa-45df-b72b-4b698a869c00@j1
    4g2000yqm.googlegroups.com>, Sat, 26 Dec 2009 11:58:43, Stefan Mueller
    <> posted:
    >I've a html table which is sortable by clicking on the header of each
    >column.
    >Because the sorting sometimes takes a couple of seconds I'd like to
    >prevent that the user can click the header of a column while the sort
    >function is running.
    >
    >Here's my approach:
    >I do at the end of the sort function
    > sort_end_time = new Date().getTime();
    >and at the beginning of the sort function I check how much time has
    >passed after the sort function finished last time
    > if ((new Date().getTime() - sort_end_time) > 300) {



    Rather than use Date, would it not be better to do something like

    Busy = true
    CallLengthySortFunction()
    Busy = false

    and test Busy at the start of your onClick routines?

    That does not address the re-draw time question.

    --
    (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
    Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
    Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7)
    Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
     
    Dr J R Stockton, Dec 27, 2009
    #5
  6. On Dec 27 2009, 10:33 pm, Dr J R Stockton
    <> wrote:
    > Rather than use Date, would it not be better to do something like
    >
    >         Busy = true
    >         CallLengthySortFunction()
    >         Busy = false
    >
    > and test Busy at the start of your onClick routines?
    >
    > That does not address the re-draw time question.


    Yes, it would be much better to do something like
    Busy = true
    CallLengthySortFunction()
    Busy = false
    But it does not work.

    The 'CallLengthySortFunction()' locks the whole javascript engine so
    that the onClick event is not executed before the
    'CallLengthySortFunction()' has finished. If you click on a column the
    onClick event is "cached" and first when the 'CallLengthySortFunction
    ()' has finished the onClick event gets executed and then 'Busy' is
    set False and not True anymore.

    That's the reason why I'm trying to do something with the time
    function.

    However, like you mentioned, even if your solution with 'Busy' would
    work I still had the problem that 'Busy = false' (last javascript
    command) is executed BEFORE the browser has redrawn (refreshed) the
    table on the screen. That means that 'Busy' is False before the user
    sees the new sorted table on the screen and that he already can click
    on another column before the newly sorted table is displayed.

    I need any possibility, any event where I can execute the command
    'Busy = false' or in my case to save the time just after the browser
    is ready again (after the refresh which sometimes takes several
    seconds).

    Stefan
     
    Stefan Mueller, Jan 7, 2010
    #6
  7. Stefan Mueller

    David Mark Guest

    On Jan 7, 4:41 am, Stefan Mueller <> wrote:
    > On Dec 27 2009, 10:33 pm, Dr J R Stockton
    >
    > <> wrote:
    > > Rather than use Date, would it not be better to do something like

    >
    > >         Busy = true
    > >         CallLengthySortFunction()
    > >         Busy = false

    >
    > > and test Busy at the start of your onClick routines?

    >
    > > That does not address the re-draw time question.


    There is no such question. ;)

    >
    > Yes, it would be much better to do something like
    >   Busy = true
    >   CallLengthySortFunction()
    >   Busy = false


    That's exactly the same. (?)

    > But it does not work.
    >
    > The 'CallLengthySortFunction()' locks the whole javascript engine so
    > that the onClick event is not executed before the
    > 'CallLengthySortFunction()' has finished. If you click on a column the
    > onClick event is "cached" and first when the 'CallLengthySortFunction
    > ()' has finished the onClick event gets executed and then 'Busy' is
    > set False and not True anymore.


    You are confused. "Cached" user actions are not going to do anything
    until you are finished with the above execution. And there's a good
    chance that the rendering will be updated on exiting the sort function
    (though that is irrelevant). Post a test page that demonstrates your
    problem as your descriptions so far can't be accurate.

    And forget anything to do with timing. Such strategies are doomed to
    fail (if not for you, then for some percentage of your users). ;)
     
    David Mark, Jan 7, 2010
    #7
  8. On Jan 7, 11:07 am, David Mark <> wrote:
    > You are confused.  "Cached" user actions are not going to do anything
    > until you are finished with the above execution.  And there's a good
    > chance that the rendering will be updated on exiting the sort function
    > (though that is irrelevant).  Post a testpagethat demonstrates your
    > problem as your descriptions so far can't be accurate.


    Here is a testpage:
    http://test.seekware.ch/example.html

    Please click once on 'Column 1' and after a few seconds the table is
    sorted (just click 'Ok' to close the message box).
    Click on 'Column 1' again and watch the message box. 'Busy' is false
    and 'Difference' shows the time elapsed after the last sorting.
    Now click 'Ok' and just again on 'Column 1' (before the sorting has
    finished). Your click will be cached and just after the sorting has
    finished the message box appears again. 'Busy' is false again and also
    'Difference' shows the time elapsed (a couple of milliseconds) after
    the last sorting again (this is the time the browser needs to refresh
    the table).

    > And forget anything to do with timing.  Such strategies are doomed to
    > fail (if not for you, then for some percentage of your users).  ;)


    I totally agree! I just thought that this could be the only
    possibility. But if there's no possibility, no event where I can save
    the time just after the browser is ready again it makes no sense.

    To sum up: I'm looking for a solution to prevent clicking on a column
    header while the table is sorting.
    The only solution I figured out is to add the command 'alert("Sorting
    done.");' at the end of the sort function because then the cached
    mouse clicks get deleted. But I don't want to display such a message
    box. Is there perhaps another way to delete these mouse clicks?

    Stefan
     
    Stefan Mueller, Jan 12, 2010
    #8
  9. Stefan Mueller

    JR Guest

    On 12 jan, 02:04, Stefan Mueller <> wrote:
    > On Jan 7, 11:07 am, David Mark <> wrote:
    >
    > > You are confused.  "Cached" user actions are not going to do anything
    > > until you are finished with the above execution.  And there's a good
    > > chance that the rendering will be updated on exiting the sort function
    > > (though that is irrelevant).  Post a testpagethat demonstrates your
    > > problem as your descriptions so far can't be accurate.

    >
    > Here is a testpage:
    >  http://test.seekware.ch/example.html
    >
    > Please click once on 'Column 1' and after a few seconds the table is
    > sorted (just click 'Ok' to close the message box).
    > Click on 'Column 1' again and watch the message box. 'Busy' is false
    > and 'Difference' shows the time elapsed after the last sorting.
    > Now click 'Ok' and just again on 'Column 1' (before the sorting has
    > finished). Your click will be cached and just after the sorting has
    > finished the message box appears again. 'Busy' is false again and also
    > 'Difference' shows the time elapsed (a couple of milliseconds) after
    > the last sorting again (this is the time the browser needs to refresh
    > the table).
    >
    > > And forget anything to do with timing.  Such strategies are doomed to
    > > fail (if not for you, then for some percentage of your users).  ;)

    >
    > I totally agree! I just thought that this could be the only
    > possibility. But if there's no possibility, no event where I can save
    > the time just after the browser is ready again it makes no sense.
    >
    > To sum up: I'm looking for a solution to prevent clicking on a column
    > header while the table is sorting.
    > The only solution I figured out is to add the command 'alert("Sorting
    > done.");' at the end of the sort function because then the cached
    > mouse clicks get deleted. But I don't want to display such a message
    > box. Is there perhaps another way to delete these mouse clicks?


    The solution is using a flag ('busy') as a property of the sort
    method:

    function sort() {
    if (arguments.callee.busy) { return; }
    arguments.callee.busy = true;
    // do the sort stuff.
    arguments.callee.busy = false;
    }

    --
    JR
     
    JR, Jan 12, 2010
    #9
  10. On Jan 12, 1:59 pm, JR <> wrote:
    > > To sum up: I'm looking for a solution to prevent clicking on a column
    > > header while the table is sorting.
    > > The only solution I figured out is to add the command 'alert("Sorting
    > > done.");' at the end of the sort function because then the cached
    > > mouse clicks get deleted. But I don't want to display such a message
    > > box. Is there perhaps another way to delete these mouse clicks?

    >
    > The solution is using a flag ('busy') as a property of the sort
    > method:
    >
    > function sort() {
    >   if (arguments.callee.busy) { return; }
    >   arguments.callee.busy = true;
    >   // do the sort stuff.
    >   arguments.callee.busy = false;


    Good idea but it doesn't work neither.

    I added it to the testpage:
    http://test.seekware.ch/example.html

    'arguments.callee.busy' is also always false.

    Stefan
     
    Stefan Mueller, Jan 12, 2010
    #10
  11. Stefan Mueller

    Jorge Guest

    On Jan 12, 8:39 pm, Stefan Mueller <> wrote:
    > On Jan 12, 1:59 pm, JR <> wrote:
    >
    > > > To sum up: I'm looking for a solution to prevent clicking on a column
    > > > header while the table is sorting.
    > > > The only solution I figured out is to add the command 'alert("Sorting
    > > > done.");' at the end of the sort function because then the cached
    > > > mouse clicks get deleted. But I don't want to display such a message
    > > > box. Is there perhaps another way to delete these mouse clicks?

    >
    > > The solution is using a flag ('busy') as a property of the sort
    > > method:

    >
    > > function sort() {
    > >   if (arguments.callee.busy) { return; }
    > >   arguments.callee.busy = true;
    > >   // do the sort stuff.
    > >   arguments.callee.busy = false;

    >
    > Good idea but it doesn't work neither.
    >
    > I added it to the testpage:
    >  http://test.seekware.ch/example.html
    >
    > 'arguments.callee.busy' is also always false.
    >
    > Stefan


    Stefan,

    All you need to do is to wrap the whole thing in a setTimeout
    (sortingCode ,0); That will warrant a redraw *before* it executes.
    Like this:

    elem.onclick= function onclick () {
    elem.onclick= null; //trash useless double-clicks
    setTimeout(function () {

    //Put your sorting code here.

    elem.onclick= onclick;
    }, 0);
    };
    --
    Jorge.
     
    Jorge, Jan 13, 2010
    #11
  12. Stefan Mueller

    David Mark Guest

    On Jan 11, 11:04 pm, Stefan Mueller <> wrote:
    > On Jan 7, 11:07 am, David Mark <> wrote:
    >
    > > You are confused. "Cached" user actions are not going to do anything
    > > until you are finished with the above execution. And there's a good
    > > chance that the rendering will be updated on exiting the sort function
    > > (though that is irrelevant). Post a testpagethat demonstrates your
    > > problem as your descriptions so far can't be accurate.

    >
    > Here is a testpage:
    > http://test.seekware.ch/example.html


    Okay. I glanced at it.

    >
    > Please click once on 'Column 1' and after a few seconds the table is
    > sorted (just click 'Ok' to close the message box).


    Yeah, it was more than a few on this machine. You have to break up that
    process, using a timeout to fire each in turn. So there's no point in
    worrying about how this version behaves.

    > Click on 'Column 1' again and watch the message box. 'Busy' is false
    > and 'Difference' shows the time elapsed after the last sorting.
    > Now click 'Ok' and just again on 'Column 1' (before the sorting has
    > finished). Your click will be cached and just after the sorting has
    > finished the message box appears again. 'Busy' is false again and also
    > 'Difference' shows the time elapsed (a couple of milliseconds) after
    > the last sorting again (this is the time the browser needs to refresh
    > the table).


    So what's the problem? And please lose the alerts as they can foul up
    these sorts of tests.

    >
    > > And forget anything to do with timing. Such strategies are doomed to
    > > fail (if not for you, then for some percentage of your users). ;)

    >
    > I totally agree! I just thought that this could be the only
    > possibility. But if there's no possibility, no event where I can save
    > the time just after the browser is ready again it makes no sense.


    I still don't see what your problem is.

    >
    > To sum up: I'm looking for a solution to prevent clicking on a column
    > header while the table is sorting.


    You can't prevent the user from clicking. You are in charge of your own
    listners though. So it is up to you...

    > The only solution I figured out is to add the command 'alert("Sorting
    > done.");' at the end of the sort function because then the cached
    > mouse clicks get deleted.


    That's an erroneous characterization, regardless of what you observed.
    You really need to stop guessing.

    > But I don't want to display such a message
    > box. Is there perhaps another way to delete these mouse clicks?


    There is no way to "delete" mouse clicks. You can, however, consult a
    "busy" flag to determine whether to act on them or not. So in a couple
    of sentences, what do you perceive the failure to be? And forget about
    when the browser re-renders the column headers (that's a red herring).
     
    David Mark, Jan 13, 2010
    #12
  13. Stefan Mueller

    David Mark Guest

    Jorge wrote:
    > On Jan 12, 8:39 pm, Stefan Mueller <> wrote:
    >> On Jan 12, 1:59 pm, JR <> wrote:
    >>
    >>>> To sum up: I'm looking for a solution to prevent clicking on a column
    >>>> header while the table is sorting.
    >>>> The only solution I figured out is to add the command 'alert("Sorting
    >>>> done.");' at the end of the sort function because then the cached
    >>>> mouse clicks get deleted. But I don't want to display such a message
    >>>> box. Is there perhaps another way to delete these mouse clicks?
    >>> The solution is using a flag ('busy') as a property of the sort
    >>> method:
    >>> function sort() {
    >>> if (arguments.callee.busy) { return; }
    >>> arguments.callee.busy = true;
    >>> // do the sort stuff.
    >>> arguments.callee.busy = false;

    >> Good idea but it doesn't work neither.
    >>
    >> I added it to the testpage:
    >> http://test.seekware.ch/example.html
    >>
    >> 'arguments.callee.busy' is also always false.
    >>
    >> Stefan

    >
    > Stefan,
    >
    > All you need to do is to wrap the whole thing in a setTimeout
    > (sortingCode ,0); That will warrant a redraw *before* it executes.


    As usual, you have no idea what you are talking about. This has
    absolutely nothing to do with any so-called "redraw". Where do you get
    this shit?

    It's a simple click listener that needs to prevent re-entry in some
    cases. How this has turned into a mystery is beyond me. If you can't
    solve this one, you can't write anything for browsers.
     
    David Mark, Jan 13, 2010
    #13
  14. Stefan Mueller

    David Mark Guest

    Hans-Georg Michna wrote:
    > On Sat, 26 Dec 2009 11:58:43 -0800 (PST), Stefan Mueller wrote:
    >
    >> Is there any possibility, any event where I can execute the command
    >> 'sort_end_time = new Date().getTime();' just after the browser is
    >> ready again (after the refresh)? In my case the command 'sort_end_time
    >> = new Date().getTime();' (the last command of the sort function) is
    >> executed before the browser starts the redraw (refresh).

    >
    > Stefan,
    >
    > check http://winhlp.com/node/633 for some basic thoughts about
    > the rendering to screen and its detection.


    It has nothing to do with that.

    >
    > But you may be trying to kill a non-existent dragon. JavaScript
    > execution is single-threaded. No second JavaScript thread can
    > start before the current one has finished.


    Exactly. And, though irrelevant for this case, it should be mentioned
    that re-flows are similarly predictable (they happen only on exiting
    execution contexts).

    >
    > Most browsers don't even render to screen, as long as any
    > JavaScript task is running, with the exception of Opera.


    That's incorrect. They virtually all re-flow on exiting an execution
    context. Though it makes no difference for this "problem" (can't stress
    that enough), it is very useful to know this.

    So if you see code that sets multiple styles and it calls a function to
    set a single style in a loop (sound familiar?), you can figure on at
    least one and maybe n re-flows during that loop. I see these patterns
    all the time and adjusting them out usually leads to huge performance
    increases (with very little effort invested), particularly for large and
    complex DOM's (the norm, of course).
     
    David Mark, Jan 13, 2010
    #14
  15. Stefan Mueller

    Jorge Guest

    On Jan 13, 9:40 am, David Mark <> wrote:
    > (...)
    > It's a simple click listener that needs to prevent re-entry in some
    > cases. (...)


    Mine not only does, but in addition warrants a redraw between sorts
    (e.g. if the user clicked on a second column while the previous sort
    was still running).
    --
    Jorge.
     
    Jorge, Jan 13, 2010
    #15
  16. Stefan Mueller

    David Mark Guest

    Jorge wrote:
    > On Jan 13, 9:40 am, David Mark <> wrote:
    >> (...)
    >> It's a simple click listener that needs to prevent re-entry in some
    >> cases. (...)

    >
    > Mine not only does, but in addition warrants a redraw between sorts
    > (e.g. if the user clicked on a second column while the previous sort
    > was still running).


    Not only does what?! And "warrants a redraw?" What do any of your
    posts mean?
     
    David Mark, Jan 13, 2010
    #16
  17. Stefan Mueller

    Jorge Guest

    On Jan 13, 10:07 am, David Mark <> wrote:
    >
    > Not only does what?!  And "warrants a redraw?"  What do any of your
    > posts mean?


    Too much thinking for you today... :)
    --
    Jorge.
     
    Jorge, Jan 13, 2010
    #17
  18. Stefan Mueller

    David Mark Guest

    Jorge wrote:
    > On Jan 13, 10:07 am, David Mark <> wrote:
    >> Not only does what?! And "warrants a redraw?" What do any of your
    >> posts mean?

    >
    > Too much thinking for you today... :)


    No, too much time reading your ludicrous one-liners. :(
     
    David Mark, Jan 13, 2010
    #18
  19. Stefan Mueller

    Jorge Guest

    On Jan 13, 10:52 am, Hans-Georg Michna <hans-
    > wrote:
    > On Wed, 13 Jan 2010 03:46:42 -0500, David Mark wrote:
    > >Hans-Georg Michna wrote:
    > >> Most browsers don't even render to screen, as long as any
    > >> JavaScript task is running, with the exception of Opera.

    > >That's incorrect.  They virtually all re-flow on exiting an execution
    > >context.  Though it makes no difference for this "problem" (can't stress
    > >that enough), it is very useful to know this.

    >
    > >So if you see code that sets multiple styles and it calls a function to
    > >set a single style in a loop (sound familiar?), you can figure on at
    > >least one and maybe n re-flows during that loop.  I see these patterns
    > >all the time and adjusting them out usually leads to huge performance
    > >increases (with very little effort invested), particularly for large and
    > >complex DOM's (the norm, of course).

    >
    > You are saying that most browsers re-render to screen while some
    > JavaScript code is still to be or being executed? I haven't seen
    > that. What I see is that the browsers, except perhaps Opera,
    > don't do anything at all on screen until the JavaScript code
    > finishes execution or is killed because it ran for too long.
    >
    > But I haven't done any exhausting tests on this. Has anybody
    > else here tested this thoroughly?


    A reflow is not a redraw. There's (usually) many (more) reflows per
    redraw. Reflows happen during normal JS execution, but redraws
    (exception: Opera) don't.
    --
    Jorge.
     
    Jorge, Jan 13, 2010
    #19
  20. Stefan Mueller

    David Mark Guest

    Hans-Georg Michna wrote:
    > On Wed, 13 Jan 2010 03:46:42 -0500, David Mark wrote:
    >
    >> Hans-Georg Michna wrote:

    >
    >>> Most browsers don't even render to screen, as long as any
    >>> JavaScript task is running, with the exception of Opera.

    >
    >> That's incorrect. They virtually all re-flow on exiting an execution
    >> context. Though it makes no difference for this "problem" (can't stress
    >> that enough), it is very useful to know this.
    >>
    >> So if you see code that sets multiple styles and it calls a function to
    >> set a single style in a loop (sound familiar?), you can figure on at
    >> least one and maybe n re-flows during that loop. I see these patterns
    >> all the time and adjusting them out usually leads to huge performance
    >> increases (with very little effort invested), particularly for large and
    >> complex DOM's (the norm, of course).

    >
    > You are saying that most browsers re-render to screen while some
    > JavaScript code is still to be or being executed?


    What I said was they re-render on exiting execution contexts. So sure
    there can still be JS to execute at that point.

    > I haven't seen
    > that.


    Look again. :)

    > What I see is that the browsers, except perhaps Opera,
    > don't do anything at all on screen until the JavaScript code
    > finishes execution or is killed because it ran for too long.


    I don't know what you think you see in Opera, but I can tell you for
    sure that it is not special in this regard. And your observations are
    incorrect.

    >
    > But I haven't done any exhausting tests on this. Has anybody
    > else here tested this thoroughly?
    >


    There's no need to do any tests on it. It's a documented fact. It's
    something you must deal with when designing UI widgets that run in
    browsers. If you don't know how re-flows work, you can't hope to write
    efficient (or consistent) widgets. It's been roughly the same game
    since IE4. The problem is that there is a tsunami of bad examples and
    associated misinformation out there on the Web, while most of the good
    stuff runs behind corporate firewalls (side by side with lots more crap
    of course).

    Looking for unnecessary re-flows and memory leak patterns is usually the
    first thing I am asked to do on a project. Most people know there are
    problems in those areas that affect performance and/or waste resources,
    but they don't know exactly what the problem is. ;)

    But the OP's "problem" has nothing to do with any of this. That one
    falls under too much execution in a listener (another common gaffe).
    Break it up into steps with timeouts and never mind when the re-flows
    happen.
     
    David Mark, Jan 13, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sanjay patil via .NET 247

    Previous(Unwanted) event handled when page refreshed by key F5

    sanjay patil via .NET 247, Apr 27, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    403
    sanjay patil via .NET 247
    Apr 27, 2004
  2. Harvey
    Replies:
    0
    Views:
    749
    Harvey
    Jul 16, 2004
  3. Harvey
    Replies:
    1
    Views:
    879
    Daniel
    Jul 16, 2004
  4. Replies:
    0
    Views:
    405
  5. Astrix
    Replies:
    2
    Views:
    576
    Astrix
    Aug 28, 2007
Loading...

Share This Page