From: Jorge on
On Apr 19, 5:49 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk>
wrote:
> In comp.lang.javascript message <90d2813b-13d1-43d3-80d4-caf4537f438c(a)j2
> 1g2000yqh.googlegroups.com>, Sun, 18 Apr 2010 04:06:20, Jorge
> <jo...(a)jorgechamorro.com> posted:
>
> >You're right: there's no better way. Currently only Opera renders DOM
> >changes to the screen in parallel with JS execution (in a separate
> >thread, or process, or whatever). I agree with you that something
> >along the lines of a ~ window.renderNow() would be a Good Thing™, and
> >it wouldn't "break the web".
>
> One should recognise that there are two extreme cases.
>
> One is like a digital clock : at every update one or more characters
> (Unicode or image) will be replaced by another of the same size, and
> nothing else will be affected.
>
> The other is like, for a long plain-text document, changing the body
> padding; the entire text will need to be re-drawn.
>
> In the first case, there is no need to postpone the drawing of any
> character, even when 23:59:59 changes to 00:00:00.  In the second case,
> that redrawing should be combined with other re-drawings until the DOM
> representation stops changing.
>
> Perhaps there should be a JavaScript Method (I don't recall seeing one)
> to immediately re-draw an Object without changing its apparent boundary
> (so that nothing else would be tempted to redraw), if the new content
> waned to be larger, it would be truncated or overflow or shrink, at the
> whim of the browser.  The method might return a Boolean to indicate
> whether that occurred.

Stockton, if you have not already, you should see this:

http://www.youtube.com/watch?v=a2_6bGNZ7bA

Enjoy.
--
Jorge.
From: Jorge on
On Apr 20, 12:29 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
>
> I have told you a different, less hackish way: threaded scripting native to
> recent JavaScript.  It is possible that other recent implementations support
> that approach, too.  Whether it qualifies as "better", though, depends on
> your definition of "better".

You mean a worker, right ?
--
Jorge.
From: Jorge on
On Apr 20, 3:54 am, Johannes Baagoe <baa...(a)baagoe.com> wrote:
> Jorge :
>
> > function time /*contextContainer*/ (elements) {
> >   function time1 (element) { ... }
> >   function resetHandlers () { ... }
>
> >   (function loop /*iCarryTheContext*/ (e) {
> >     if (e= elements.shift()) reset(e), time1(e); if (elements.length)
> >     setTimeout(loop, 0); else resetHandlers();
> >   })();
> > }
>
> I quite like that, many thanks. I have changed my code accordingly
> onhttp://baagoe.com/en/RandomMusings/javascript/time.js
>
> (With one tiny change, though - but which may be worth a separate
> thread, since it is a detail that appears again and again in
> javascript, and has not particular relevance to window refreshing
> via the DOM.)

My suggestion is this one:

function time(elements) {

function time1(element) {
function nop() {
return;
}

var n = document.getElementById('n').value;
var n1 = n;
var toDo = element.id.split(/-/);

var gen = generators[toDo[0]]();
if (toDo[1] != 'default') {
gen = gen[toDo[1]];
}

var start = new Date();
while (n--) {
gen();
}
var stop = new Date();
var generatorTime = stop - start;

var start = new Date();
while (n1--) {
nop();
}
var stop = new Date();
var nopTime = stop - start;

element.appendChild(document.createTextNode(generatorTime -
nopTime));
//resets the highlighting.
setTimeout(function () {
element.style.color= "";
element.style.backgroundColor= "";
}, 333);
}

function loop(e) {
if (e = elements.shift()) {
//I wonder why do you insist in putting here a setTimeout... ¿?
time1(e);
}

if (elements.length) {
window.setTimeout(loop, 0); //loop asap
} else {
document.getElementById('timeAll').setAttribute('onclick',
'timeAll();');
var cells = document.getElementsByTagName('td');
for (var i = 0; i < cells.length; i++) {
cells[i].setAttribute('onclick', 'time([this])');
}
}
}

//clears and highlights the cells we're about to update:
elements.forEach(function (e) {
reset(e);
e.style.color= "#ff0000";
e.style.backgroundColor= "#ffe0e0";
});

//This setTimeout gives the browser a chance to render
//the reset()s above.
setTimeout(loop, 0);
}
--
Jorge.
From: Dr J R Stockton on
In comp.lang.javascript message <90d2813b-13d1-43d3-80d4-caf4537f438c(a)j2
1g2000yqh.googlegroups.com>, Sun, 18 Apr 2010 04:06:20, Jorge
<jorge(a)jorgechamorro.com> posted:

>You're right: there's no better way. Currently only Opera renders DOM
>changes to the screen in parallel with JS execution (in a separate
>thread, or process, or whatever). I agree with you that something
>along the lines of a ~ window.renderNow() would be a Good Thing™, and
>it wouldn't "break the web".

One should recognise that there are two extreme cases.

One is like a digital clock : at every update one or more characters
(Unicode or image) will be replaced by another of the same size, and
nothing else will be affected.

The other is like, for a long plain-text document, changing the body
padding; the entire text will need to be re-drawn.


In the first case, there is no need to postpone the drawing of any
character, even when 23:59:59 changes to 00:00:00. In the second case,
that redrawing should be combined with other re-drawings until the DOM
representation stops changing.

Perhaps there should be a JavaScript Method (I don't recall seeing one)
to immediately re-draw an Object without changing its apparent boundary
(so that nothing else would be tempted to redraw), if the new content
waned to be larger, it would be truncated or overflow or shrink, at the
whim of the browser. The method might return a Boolean to indicate
whether that occurred.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
From: Jeremy J Starcher on
On Sun, 18 Apr 2010 02:33:50 +0200, Thomas 'PointedEars' Lahn wrote:

> Jeremy J Starcher wrote:
>
>> The browser window is single threaded.
>
> Where did you get that piece of "wisdom" from?

The same place we get the wisdom about other things that are not exactly
specified in the specifications, or the same way we get the wisdom that
things that /are/ in the specs yet implemented poorly.

By observation and a bit of logic.

There is nothing in the HTML, HTTP or ECMA scripts that requires multi-
threading. While it is true that many browsers do include some form of
threading to allow concurrent downloading of resources, fully compliant
web browser may be coded as a single process and single thread.

It may not be an efficient design, but done correctly it would be a
standards compliant one.

(tab == window for the sake of this discussion. An instance of the
window object)
It is a task left to the reader to observe that in most browsers, the
user-interface for a window will freeze during ECMAScript execution and
during reflows. This is correct behavior since the standards do not
indicate that any result should happen.

Therefore, from the user and programmer's view, there is only one thread
per window. IF there are other threads, that is an implantation specific
detail and should not be relied upon.

Likewise, updating the status and title bar /may/ be carried out by the
thread the window object is running in, or it may be carried out by
another thread in the application. AFAICT, that behavior is undefined as
well.

Therefore, my "wisdom" about the window only having one thread.

Just like there are only two people who live in my house. There /may/ be
other people with zero mass and an inability to effect anything around
them, but since I can neither tell they are there -- nor would their
presence alter anything at all, I still say there are only two people
living in my house. Even if I can't disprove the others are not there.