DOM latency

[Darko]

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

[VK]

On Feb 26, 7:29 pm, "Darko" <[e-mail]:

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.

[Darko]

On Feb 26, 5:53 pm, "VK" <[e-mail]:

On Feb 26, 7:29 pm, "Darko" <[e-mail]:

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.

[VK]

On Feb 26, 8:16 pm, "Darko" <[e-mail]:

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).

[RobG]

On Feb 27, 5:57 am, "VK" <[e-mail]:
....]

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

[VK]

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*

[RobG]

On Feb 27, 2:29 am, "Darko" <[e-mail]:

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]

On Feb 27, 7:31 am, "VK" <[e-mail]:

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

[Darko]

On Feb 27, 12:37 am, "RobG" <[e-mail]:

On Feb 27, 2:29 am, "Darko" <[e-mail]:

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