Page transition question

[Workgroups]

I've got a page where the nature of the beast is such that the user clicks a
submit button to ransomize some data in somewhat rapid succession (once per
second, give or take). The page generates a little table, 10x10, of small
pictures that represent the randomized data. The submit button tells the
server (which is keeping track of which pictures are where) to scramble them
around and output a new table. The output is simple HTML. The scrambling
needs to occur server-side, so I can't do the obvious thing, which would be
to simply scramble the pics around with JS. I have to do the actual
scrambling on the server.

So I created a page to do this task, and in the two browsers I've tested so
far (IE 6 and FF 1.0.6) there's a somewhat annoying little graphical anomoly
I'd like to eliminate, if I can. This all happens very quickly:

- user clicks submit

- browser "clears the screen", awaiting new data from postback <- can
create a "flicker"

- browser renders the postback

(repeat)

Now on some submit clicks (in either browser), the browser renders the new
postback data over the old data so encredibly fast (this is for an intranet
on a LAN btw, and the 'scrambling' process takes less than 1/1000th of a
second, and all pictures are cached on the client) that it the data on the
page, visually, the little graphics simply "shift" from one place to
another. It's so fast that, visually, the postback is transparent and it
almost looks as if I used JS to move the images. I honestly don't know if
the screen really gets cleared in between these, or the browser is only
updating parts of the screen it needs to.

But on other submits (in either browser), you can visually catch the browser
"clearing the window" so to speak, prior to renderning the postback.
Clicking the submit button in rapid succession results in a bit of a "strobe
effect" as the browser can sometimes flash "blank" very rapidly, in between
submit clicks. Perhaps the server delivery is just not *quite* fast enough
to have look "instantaneous" on some requests. Although IE tends to
"flicker" in this manner more often than FF, both browsers display the same
behavior given enough clicking.

So my question is, would it be possible to implement JS that forced every
click to look like a smooth one, maybe something like this:

- user clicks submit

- JS immediately instructs the browser to not "repaint" (et al) so that the
current page reamins in the browser without being "cleared" prior to the
postback arrival. (eliminate the "flicker")

- postback html is completely received by the browser (browser is still
displaying the "previous" page)

- JS instructs the browser to render the new postback directly without
"clearning" first, so that new data "instantly" replaces the old.

Are there aspects of JS/DOM I can research to accomplish something like
this, or am I more or less at the mercy of any given browsers display
mechanics here?

 

[ASM]

I've got a page where the nature of the beast is such that the user clicks a
submit button to ransomize some data in somewhat rapid succession (once per
second, give or take). The page generates a little table, 10x10, of small
pictures that represent the randomized data. The submit button tells the
server (which is keeping track of which pictures are where) to scramble them
around and output a new table. The output is simple HTML. The scrambling
needs to occur server-side, so I can't do the obvious thing, which would be
to simply scramble the pics around with JS. I have to do the actual
scrambling on the server.

So I created a page to do this task, and in the two browsers I've tested so
far (IE 6 and FF 1.0.6) there's a somewhat annoying little graphical anomoly
I'd like to eliminate, if I can. This all happens very quickly:

perhaps, on submit, could you ask to JS to delete the images one by one
from table (in fact, to replace images by a white one)
before to accept to submit

<script type="text/javascript">
var ig = 0, imgs = 100, timer = 100;
function send() { document.forms[0].submiter.disable=true; ig=0; del();}
function del() {
if(document.images) {
document.images[ig].src = 'white.gif';
ig++
if(ig<imgs) setTimeout('del()',timer);
else
return true;
}
}
</script>
<form action="randomizeImages.php" onsubmit="return send()">
<table>
<tr>
<td>
<img src="011.gif">
</td>
.... / ...
</table>
<input type="submit" name="submiter" value="random">
</form>

---------
other (not too good if JS disabled) :
send a page with 100 white images
do the php writes new order of images ('001','025','111', ....)
in javascript code
ask to JS to affect the images given

<script type="text/javascript">
var ig = 0, imgs = 100, timer = 300;
var I = new Array(<?php $Images php?>);
function affiche() {
if(document.images) {
for(var i=0;i<I.length;i++)
document.images.src = I+'.gif';
}
}
function imgs() {setTimeout('affiche()',timer);}
onload = img;
</script>
<form action="randomizeImages.php">
<table>
<tr>
<td>
<img src="white.gif">
</td>
.... / ...
</table>
<input type="submit" name="submiter" value="random">
</form>

------------
other :
JS do the form in css non visible
then, after loading, JS gives visibility to table

<script type="text/javascript">
document.write('<style type="text/css">'+
'form{visibility:hidden}<\/style>');
function visibl() {
document.forms[0].style.visibility='visible';
}
function doVisibl() { setTimeout('visibl()',200); }
onload=doVisibl;
</script>
<style type="text/css">
h1 { text-align: center; color: red }
form { position: absolute; top: 5px;}
</style>
</head>
<body>
<h1>Pease wait randomize ...</h1>
<form action="randomizeImages.php">
<table>
<tr>
<td>
<img src="011.gif">
</td>
.... / ...
</table>
<input type="submit" name="submiter" value="random">
</form>

 

[Workgroups]

perhaps, on submit, could you ask to JS to delete the images one by one
from table (in fact, to replace images by a white one)
before to accept to submit

Thanks for the reply. Let me restate what I'm trying to solve. Server side
processing, images & tables are perhaps misleading elements. Here's is a
more simplified example containing the same problem:

I have an HTML page called index.html that contains only text, with a link:

"This is the default page. Click here to see page 2."

"Page 2", when the user clicks the link, contains only this text:

"Hello! This is Page 2"

A user sits down to visit the website. Imagine we point a high-speed camera
at the monitor and begin filming.

The user visits the website and in the browser appears the text from the
default page: "This is the default page. Click here to see page 2."

They click on the link and now their browser the screen says "Hello! This
is Page 2".

If you were to now go back to your high-speed video and watch the user click
the link in very slow motion, you would see the following:

1. The browser window says "This is the default page. Click here to see
page 2."

2. The user clicks the link

3. The browser icon begins to animate while the browser waits for server to
respond to request

4. The browser window "clears" itself, preparing for the next page. The
more HTML you have, the longer this phase takes. In our case, it is very
very fast, but it still exists.

5. "Hello! This is Page 2" appears in the browser window as the next page
arrives.

This "clearing" on step 4 is what I am trying to eliminate. I want the
browser to do this instead:

1. The browser window says "This is the default page. Click here to see
page 2."

2. The user clicks the link

3. The browser icon begins to animate while the browser waits for server to
respond to request. "This is the default page. Click here to see page 2."
remains in the window.

4. "Hello! This is Page 2" immediately replaces the contents of the window.

I want to see if I can stop the browser from "clearing" between requests,
and instead, continue displaying the first page until the next is ready to
be rendered.

 

[Workgroups]

The flicker is due to the server request and time it takes for it be
served,

That's what I'm trying to override (well, visually override). I understand
it takes time to request/process/reply but what I'm shooting for here is
some way to have the browser remain visually static until the response is
complete.

why can't you use js instead of the server language again?

The data is centralized on the server. Multiple clients visiting the
website & requesting the current state of the data must always see the same
set of data.

For security/integrity reasons, clients aren't allowed to perform the
scrambling. They may only request the server scramble it on their behalf.

 

[RobG]

I've got a page where the nature of the beast is such that the user clicks a
submit button to ransomize some data in somewhat rapid succession (once per
second, give or take). The page generates a little table, 10x10, of small
pictures that represent the randomized data. The submit button tells the
server (which is keeping track of which pictures are where) to scramble them
around and output a new table. The output is simple HTML. The scrambling
needs to occur server-side, so I can't do the obvious thing, which would be
to simply scramble the pics around with JS. I have to do the actual
scrambling on the server.

[...]

Try:

1. Create an array of image references - say your images are in a
table, use getElementsByTagName to get all the images in the table.

2. Create an array of keys and assign key:imageRef pairs to an object

3. Store the image src attributes in a source array

4. Store the keys in a key array

5. Use HTTPRequest or hidden frame to send the key array to the server
for shuffling.

6. Re-assign image src attributes based on the shuffled keys

You could save a lot of trouble if the image src array itself was
shuffled, rather than the keys, then you'd just need an array of image
references and and another of sources, shuffle the src array and
re-assign to image refs.

But I figured using keys is significantly less data to exchange and
likely much faster as a result.

The key array could be just kept in the key:ref object, then on each
shuffle it would be copied and shuffled, but having a separate array is
likely more efficient.

Initialise the objects onload and shuffle the keys. Then at a set
interval (or on some event), re-assign the images then shuffle the keys
again. That way the key shuffle/data exchange should be complete by the
time you next re-assign images.

Where the call is made to Shuffle() is where you'd do your server
communication.


<script type="text/javascript">

/* Adapted from: http://www.merlyn.demon.co.uk/js-randm.htm#SDFS */
function Shuffle(Q) {
var R, T, J = Q.length;
while ( J-- ) {
R = Random(J + 1);
T = Q[J];
Q[J] = Q[R];
Q[R] = T;
}
return Q;
}

/* From: http://www.merlyn.demon.co.uk/js-randm.htm#AfR */
function Random(N) {
return Math.floor(N * (Math.random() % 1));
}

// Global variables
var iSrcArray = []; // Image src to assign to refs
var iKeyArray = []; // Keys to shuffle
var keyRefObj = {}; // Holds key : ref pairs
var shuffleTimer = null;

function initImgShuffle ( sA, kA, rk, el ) {
var rA = el.getElementsByTagName( 'img' );
var i = rA.length;
while ( i-- ) {
kA = 'k-' + i;
rk[ kA ] = rA;
sA = rA.src;
}
}

function shuffleImages( sA, kA, kr ) {
for ( var i in kA ) { kr[ kA ].src = sA; }
Shuffle( kA );
}

window.onload = function () {
initImgShuffle( iSrcArray, iKeyArray, keyRefObj,
document.getElementById('XX') );
Shuffle( iKeyArray );
shuffleTimer = setInterval( function() {
shuffleImages( iSrcArray, iKeyArray, keyRefObj);
}, 2000);
}

</script>

<input type="button" value="Stop shuffle" onclick="
if ( shuffleTimer ) {
window.clearInterval( shuffleTimer );
shuffleTimer = null;
}
">

<table id="XX">
<!-- Just a shortcut for putting 64 test images into the page -->
<script type="text/javascript">
var i, j, k=8, t=[];
var cS = '<td><img src="';
var cE = '" height="100" width="100"></td>';
for ( i=0; i<k; i++ ){
t.push('<tr>');
for ( j=0; j<2; j++ ) {
t.push( cS + 'a.jpg' + cE);
t.push( cS + 'b.jpg' + cE);
t.push( cS + 'c.gif' + cE);
t.push( cS + 'd.gif' + cE);
}
t.push('</tr>');
}
document.write( t.join('') );
</script>
</table>

 

[Tim Williams]

If the server really needs to do the shuffling then you could use
xmlhttp to get the next shuffled "set" from the server. Use the return
value to re-arrange the pictures in the table. Less data is
transferred since you're only getting the order and not the whole page
each time, so the whole update should be faster.


Tim.

 

[ASM]

Thanks for the reply. Let me restate what I'm trying to solve.

OK
so : same answer as : RobG -> use frames or iframe
but simpliest way ... ! ? (very few JS)

- Main page with :
- table 10/10 (clone of yours)
each TD contains an image ( white.gif )
- button to call your server-side page
<form action="page.php" target="myIframe" method="get">
<input type="hidden" name="indice">
<input type=submit onclick="indice.value=i++;
this.value='Wait during loading ...';
this.style.color='red';" value="GO">
</form>
- iframe set to 0 and/or non-display
<iframe src="page.php" style="display:none" onload="parent.go();">
your browser can't display an iframe
</iframe>
- few javascript :
<script type="text/javascript">
var i = 1;
function go() {
var P = document.images;
var F = parent.myIframe.document.images;
var k = 0;
while(k<P.length) P[k].src=F[k].src;
with(document.forms[0][1]) {value='GO';style.color='green';}
}
</script>

page.php figures your clever page on your server
would only contains its table and 100 images (not more)

and I hope the onload of iframe will work on each call ... ( ? )
(it would do as url asked is always different of precedent)

 

[Workgroups]

For the record I managed to solve this for my scenario, unfortuantely w/o
JS. So this is for the googlers...

By default, FireFox v1.0.6 generally performs page transitions in what I
suppose you could call a more "graceful" fashion than IE 6. The FF browser
appears to make a decided effort to only repaint portions of the display
that it needs to between postbacks. After more study, and eliminating some
HTML bulk to reduce response time, and by reusing images known to have been
previously sent (cached), after a few postbacks the FF browser eventually
reaches a state where each subsequent postback is "smooth" and free from
"flicker".

This left IE the habitual flickerer. IE can be made to behave in an
identical way to the FF browser by utilizing a proprietary META tag, to
specify page transition, albeit in somewhat unorthadox fashion:

<meta http-equiv="Page-Exit" content="blendTrans(Duration=0)">

By assigning a duration of 0 to the transition effect (I assume you could
use any effect you wanted, since the duration is 0, the type is likely to be
moot), no page transition effect will actually be rendered. However, in
seeing this tag and in preparation to perform a transition, IE knows it must
render "one page on top of the other" to complete the visual effect. IE
will leave "page 1" rendered on the screen waiting for "page 2" to arrive.
But, since the effect has a duration time of 0, the actual rendering of the
effect is skipped, and page 2 is simply rendered instantly once it arrives
fully in the client. The net result of this technique eliminates the
"flicker" of IE clearing it's screen between postbacks.

Non IE browsers will simply ignore the tag, which is just as well.