DOM latency

Discussion in 'Javascript' started by Darko, Feb 26, 2007.

  1. Darko

    Darko Guest

    Hi,

    I have a problem that seems to be related to DOM latency in executing
    instructions. How I see the situation, if one line of code produces a
    lot of inner instructions, then the engine is slowly executing them
    while allowing the following lines of code to be executed as well.

    I had similar problems earlier when I tried to put elements into an
    existing container on the page, rendering the new elements on the fly.
    I solved the problem by first generating the whole container in memory
    and then inserting it into a document subtree. But now I have the same
    problem, which can be seen in the following pseudo code:

    // GENERATE A BIG OBJECT IN MEMORY
    // RESTRUCTURE THE BIG OBJECT BY REARRANGING ITS (BIG) SUBOBJECTS
    // USE THE BIG OBJECT IN RENDERING THE PAGE

    It seems that restructuring the big object doesn't finish before its
    elements are used in the next phase, rendering the page, and what we
    get is partially correct data on the page, and partially the data from
    previous data order in the object. I tried to prove to myself that
    this is what is happening, by making a slight time delay between the
    second and the third phase in the above pseudo-code, e.g. 1 sec., and
    it seems to be working - all the data on the page is correctly
    displayed.

    Now my question is: if this is true, and the mechanism works as I
    described it, how do I correct the code? I don't think there's some
    way of "flushing" the instructions to make sure they're all completely
    executed, but maybe there is? Do you have some other way of solving
    the problem, or do you have an advice for avoiding it?

    Thank you for any answer or idea,

    Darko
     
    Darko, Feb 26, 2007
    #1
    1. Advertising

  2. Darko

    VK Guest

    On Feb 26, 7:29 pm, "Darko" <> wrote:
    > Hi,
    >
    > I have a problem that seems to be related to DOM latency in executing
    > instructions. How I see the situation, if one line of code produces a
    > lot of inner instructions, then the engine is slowly executing them
    > while allowing the following lines of code to be executed as well.
    >
    > I had similar problems earlier when I tried to put elements into an
    > existing container on the page, rendering the new elements on the fly.
    > I solved the problem by first generating the whole container in memory
    > and then inserting it into a document subtree. But now I have the same
    > problem, which can be seen in the following pseudo code:
    >
    > // GENERATE A BIG OBJECT IN MEMORY
    > // RESTRUCTURE THE BIG OBJECT BY REARRANGING ITS (BIG) SUBOBJECTS
    > // USE THE BIG OBJECT IN RENDERING THE PAGE
    >
    > It seems that restructuring the big object doesn't finish before its
    > elements are used in the next phase, rendering the page, and what we
    > get is partially correct data on the page, and partially the data from
    > previous data order in the object. I tried to prove to myself that
    > this is what is happening, by making a slight time delay between the
    > second and the third phase in the above pseudo-code, e.g. 1 sec., and
    > it seems to be working - all the data on the page is correctly
    > displayed.
    >
    > Now my question is: if this is true, and the mechanism works as I
    > described it, how do I correct the code? I don't think there's some
    > way of "flushing" the instructions to make sure they're all completely
    > executed, but maybe there is? Do you have some other way of solving
    > the problem, or do you have an advice for avoiding it?
    >
    > Thank you for any answer or idea,
    >
    > Darko


    Browsers do implement delayed graphics context update. If some method
    changed DOM property affecting graphics context, the actual repaint
    will be made only after finishing the current execution flaw and
    returning to the event waiting mode:

    function doSomething() {
    document.getElementById('myDiv').style.visibility = 'visible';
    // DOM interface value is changed, but graphics context not -
    // myDiv remains hidden because the current execution flaw
    // so far continues
    for (var i=0; i<10000; i++) {
    // do something
    }
    }

    doSomething();
    // end of the current execution flaw, myDiv becomes visible.


    It is annoying that javascript doesn't have repaint() method or
    similar. The workaround is to apply DOM changes, then give a micro-
    interruption of the flaw then continue.

    function doSomething() {
    document.getElementById('myDiv').style.visibility = 'visible';
    window.setTimeout(doTheRest, 50);
    }

    You are basically discovered this workaround by yourself - but there
    is no need to give such huge delays like 1sec. It is important to
    _have_ an interruption - the delay itself has no importance, so
    10ms-50ms are the regular values.
     
    VK, Feb 26, 2007
    #2
    1. Advertising

  3. Darko

    Darko Guest

    On Feb 26, 5:53 pm, "VK" <> wrote:
    > On Feb 26, 7:29 pm, "Darko" <> wrote:
    >
    >
    >
    > > Hi,

    >
    > > I have a problem that seems to be related to DOM latency in executing
    > > instructions. How I see the situation, if one line of code produces a
    > > lot of inner instructions, then the engine is slowly executing them
    > > while allowing the following lines of code to be executed as well.

    >
    > > I had similar problems earlier when I tried to put elements into an
    > > existing container on the page, rendering the new elements on the fly.
    > > I solved the problem by first generating the whole container in memory
    > > and then inserting it into a document subtree. But now I have the same
    > > problem, which can be seen in the following pseudo code:

    >
    > > // GENERATE A BIG OBJECT IN MEMORY
    > > // RESTRUCTURE THE BIG OBJECT BY REARRANGING ITS (BIG) SUBOBJECTS
    > > // USE THE BIG OBJECT IN RENDERING THE PAGE

    >
    > > It seems that restructuring the big object doesn't finish before its
    > > elements are used in the next phase, rendering the page, and what we
    > > get is partially correct data on the page, and partially the data from
    > > previous data order in the object. I tried to prove to myself that
    > > this is what is happening, by making a slight time delay between the
    > > second and the third phase in the above pseudo-code, e.g. 1 sec., and
    > > it seems to be working - all the data on the page is correctly
    > > displayed.

    >
    > > Now my question is: if this is true, and the mechanism works as I
    > > described it, how do I correct the code? I don't think there's some
    > > way of "flushing" the instructions to make sure they're all completely
    > > executed, but maybe there is? Do you have some other way of solving
    > > the problem, or do you have an advice for avoiding it?

    >
    > > Thank you for any answer or idea,

    >
    > > Darko

    >
    > Browsers do implement delayed graphics context update. If some method
    > changed DOM property affecting graphics context, the actual repaint
    > will be made only after finishing the current execution flaw and
    > returning to the event waiting mode:
    >
    > function doSomething() {
    > document.getElementById('myDiv').style.visibility = 'visible';
    > // DOM interface value is changed, but graphics context not -
    > // myDiv remains hidden because the current execution flaw
    > // so far continues
    > for (var i=0; i<10000; i++) {
    > // do something
    > }
    >
    > }
    >
    > doSomething();
    > // end of the current execution flaw, myDiv becomes visible.
    >
    > It is annoying that javascript doesn't have repaint() method or
    > similar. The workaround is to apply DOM changes, then give a micro-
    > interruption of the flaw then continue.
    >
    > function doSomething() {
    > document.getElementById('myDiv').style.visibility = 'visible';
    > window.setTimeout(doTheRest, 50);
    >
    > }
    >
    > You are basically discovered this workaround by yourself - but there
    > is no need to give such huge delays like 1sec. It is important to
    > _have_ an interruption - the delay itself has no importance, so
    > 10ms-50ms are the regular values.


    Thank you for your reply! But, repainting is not the only problem. As
    I've described above, the problem appears even before I put anything
    to the screen, i.e. if I fetch information from the object in memory
    that hasn't yet been finished rearranging its structure, although the
    instructions for restructuring have been given in previous line of
    code. Then, just after all of that do I put the (dis-)information to
    the screen.
     
    Darko, Feb 26, 2007
    #3
  4. Darko

    VK Guest

    On Feb 26, 8:16 pm, "Darko" <> wrote:
    > Thank you for your reply! But, repainting is not the only problem. As
    > I've described above, the problem appears even before I put anything
    > to the screen, i.e. if I fetch information from the object in memory
    > that hasn't yet been finished rearranging its structure, although the
    > instructions for restructuring have been given in previous line of
    > code. Then, just after all of that do I put the (dis-)information to
    > the screen.


    In Web applications the term "object" becomes rather ambiguous.
    There are javascript objects from native and custom constructors like
    Array, Date, Object, MyObject etc.
    There are scriptable DOM interfaces exposed by DOM Elements.
    There are DOM Tree fragments, nodes and node attributes.

    All those are very different. This is why a code fragment or a URL
    would be more helpful than an abstract schema. That would let to see
    where your rendering problems are residing.

    >From what are you saying I guess you are working not with javascript

    objects but with virtual DOM elements of a kind:
    var myDIV = document.createElement('div');
    myDiv.x = y;
    ..
    myDiv.y = z;
    ...

    Anything close to the reality?


    MVC pattern over behaviors/bindings is regularly a more convenient
    approach but alas still lacking universal support (Safari out, Opera
    out).
     
    VK, Feb 26, 2007
    #4
  5. Darko

    RobG Guest

    On Feb 27, 5:57 am, "VK" <> wrote:
    ....]
    > Anything close to the reality?
    >
    > MVC pattern over behaviors/bindings is regularly a more convenient
    > approach but alas still lacking universal support (Safari out, Opera
    > out).


    What? Are you refering to the model-view-controler architectural
    pattern? If so, I can't see how it has anything to do wither either
    Safari or Opera (or any other browser) in particular.

    MVC is not even specific to the web, it was first developed a decade
    before the web existed.


    --
    Rob
     
    RobG, Feb 26, 2007
    #5
  6. Darko

    VK Guest

    > > MVC pattern over behaviors/bindings is regularly a more convenient
    > > approach but alas still lacking universal support (Safari out, Opera
    > > out).

    >
    > What? Are you refering to the model-view-controler architectural
    > pattern? If so, I can't see how it has anything to do wither either
    > Safari or Opera (or any other browser) in particular.
    >
    > MVC is not even specific to the web, it was first developed a decade
    > before the web existed.


    MVC pattern *over behaviors/bindings*
     
    VK, Feb 26, 2007
    #6
  7. Darko

    RobG Guest

    On Feb 27, 2:29 am, "Darko" <> wrote:
    > Hi,
    >
    > I have a problem that seems to be related to DOM latency in executing
    > instructions. How I see the situation, if one line of code produces a
    > lot of inner instructions, then the engine is slowly executing them
    > while allowing the following lines of code to be executed as well.
    >
    > I had similar problems earlier when I tried to put elements into an
    > existing container on the page, rendering the new elements on the fly.
    > I solved the problem by first generating the whole container in memory
    > and then inserting it into a document subtree. But now I have the same
    > problem, which can be seen in the following pseudo code:
    >
    > // GENERATE A BIG OBJECT IN MEMORY
    > // RESTRUCTURE THE BIG OBJECT BY REARRANGING ITS (BIG) SUBOBJECTS
    > // USE THE BIG OBJECT IN RENDERING THE PAGE


    What methods are you using? W3C DOM? innerHTML? Some custom library?


    > It seems that restructuring the big object doesn't finish before its
    > elements are used in the next phase, rendering the page, and what we
    > get is partially correct data on the page, and partially the data from
    > previous data order in the object. I tried to prove to myself that
    > this is what is happening, by making a slight time delay between the
    > second and the third phase in the above pseudo-code, e.g. 1 sec., and
    > it seems to be working - all the data on the page is correctly
    > displayed.
    >
    > Now my question is: if this is true, and the mechanism works as I
    > described it, how do I correct the code?


    Impossible to say without seeing the code - post a link or minimal
    example.


    --
    Rob
     
    RobG, Feb 26, 2007
    #7
  8. Darko

    RobG Guest

    On Feb 27, 7:31 am, "VK" <> wrote:
    > > > MVC pattern over behaviors/bindings is regularly a more convenient
    > > > approach but alas still lacking universal support (Safari out, Opera
    > > > out).

    >
    > > What? Are you refering to the model-view-controler architectural
    > > pattern? If so, I can't see how it has anything to do wither either
    > > Safari or Opera (or any other browser) in particular.

    >
    > > MVC is not even specific to the web, it was first developed a decade
    > > before the web existed.

    >
    > MVC pattern *over behaviors/bindings*


    The OP didn't mention anything what-so-ever about either "behaviors"
    or "bindings" - they are irrelevant. The question seemed to be about
    whether DOM objects are created in a separate process, and that
    process may not be finished before the original process makes use of
    the objects it's creating.

    The OP might be using a big string of HTML with innerHTML, or maybe
    XHR, both of which *might* give the result described in particular
    circumstances - but until the OP explains further, it is impossible to
    tell. Rabbiting on about MVC, bindings, behaviours, certain browser
    an other things totally unrelated to the question is a pointless waste
    of time.


    --
    Rob
     
    RobG, Feb 26, 2007
    #8
  9. Darko

    Darko Guest

    On Feb 27, 12:37 am, "RobG" <> wrote:
    > On Feb 27, 2:29 am, "Darko" <> wrote:
    >
    >
    >
    > > Hi,

    >
    > > I have a problem that seems to be related to DOM latency in executing
    > > instructions. How I see the situation, if one line of code produces a
    > > lot of inner instructions, then the engine is slowly executing them
    > > while allowing the following lines of code to be executed as well.

    >
    > > I had similar problems earlier when I tried to put elements into an
    > > existing container on the page, rendering the new elements on the fly.
    > > I solved the problem by first generating the whole container in memory
    > > and then inserting it into a document subtree. But now I have the same
    > > problem, which can be seen in the following pseudo code:

    >
    > > // GENERATE A BIG OBJECT IN MEMORY
    > > // RESTRUCTURE THE BIG OBJECT BY REARRANGING ITS (BIG) SUBOBJECTS
    > > // USE THE BIG OBJECT IN RENDERING THE PAGE

    >
    > What methods are you using? W3C DOM? innerHTML? Some custom library?
    >
    > > It seems that restructuring the big object doesn't finish before its
    > > elements are used in the next phase, rendering the page, and what we
    > > get is partially correct data on the page, and partially the data from
    > > previous data order in the object. I tried to prove to myself that
    > > this is what is happening, by making a slight time delay between the
    > > second and the third phase in the above pseudo-code, e.g. 1 sec., and
    > > it seems to be working - all the data on the page is correctly
    > > displayed.

    >
    > > Now my question is: if this is true, and the mechanism works as I
    > > described it, how do I correct the code?

    >
    > Impossible to say without seeing the code - post a link or minimal
    > example.
    >
    > --
    > Rob


    Well, if that is going to be helpful, I will describe precisely what I
    use, since at the moment my javascript code is many kilobytes heavy,
    and I don't think you would be glad to read it. Anyway, I use Ajax to
    drag the data from the server. The data is described in XML, so I make
    use of the integrated xml-parser in javascript to make a DOM-element
    from it. Then I use a set of my classes to generate a tree that
    reflects about the same structure as the xml itself, accompanied with
    a lot of useful (to me) methods. Now, once I have the tree, I start
    generating the HTML by using existing elements in the document, that
    serve as templates which I clone when I need it. Once in a while, the
    user might be eager to rearrange the objects in the tree, so they're
    sorted differently etc. When he decides to do that, I call a
    corresponding method that sorts the big object, and then printAll()
    object to regenerate the HTML. However, this is where the problem
    appears - the sorting seems not to be completely rearranged, and
    printing already commences - thus I end with an incorrectly generated
    HTML with wrong strings etc.

    P.S. The classes I'm talking about here all the time is ordinary
    "function ClassName(index) { this.index=index; }
    ClassName.prototype.methodName = function() { /* ... */ }" js syntax.

    Thank you again for your interest, I haven't succeeded to make it work
    yet.

    Darko
     
    Darko, Feb 27, 2007
    #9
    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. =?Utf-8?B?YWdlaG0=?=
    Replies:
    0
    Views:
    359
    =?Utf-8?B?YWdlaG0=?=
    Sep 20, 2004
  2. Replies:
    0
    Views:
    500
  3. Replies:
    5
    Views:
    422
  4. Dave
    Replies:
    1
    Views:
    6,217
    David White
    Jan 28, 2004
  5. Darko

    DOM latency

    Darko, Feb 26, 2007, in forum: Javascript
    Replies:
    0
    Views:
    119
    Darko
    Feb 26, 2007
Loading...

Share This Page