I'm having trouble reading a javascript variable from QML. I know this seems easy, but this is a particular case :
I'm using canvas3D for generating lots of 3D Spheres and, as the instenciation is really long, I want to display a progress bar.
To do that, I've done this :
import "test6.js" as GLCode
Item {
id: mainview
width: 1280
height: 768
visible: true
// THE PROGRESS BAR
ProgressBar {
id : progressBar
anchors.centerIn: parent
value: canvas3d.progress
z:1
}
//THE CANVAS3D (WebGL)
Canvas3D {
id: canvas3d
anchors.fill: parent
focus: true
property double progress:0 //MY VARIABLE I WANT TO UPDATE FROM test6.js
property var list : []
// Emitted when one time initializations should happen
onInitializeGL: {
GLCode.initializeGL(canvas3d);
}
I have a property name progress in my canvas3d which I'm trying to modify from the test6.js script
In the initializeGL(canvas3d) function I'm updating the value of progress each time I add a sphere :
for ( i = 0; i < spheresNum; i ++ ) {
var x = list[i][0];
var y = list[i][1];
var z = list[i][2];
drawSphere(x,y,z,i);
canvas3d.progress = i/spheresNum*100;
}
Now, the problem is that I get the updated value of progress only when initializeGL() ends. Right now it's like :
Progress Bar to 0%
(Waiting for all the sphere to be instanciated)
(initializeGL() ends)
Progress Bar to 100%
Which is useless. I would prefer having the bar moving each time a sphere is created.
Do you know how can I do that ?
You only see 0% and 100% as progress, because the for-loop in initializeGL() is fully executed before the QML engine will respond to the changed value of canvas3d.progress and update the value of progessBar.value. The for-loop and the updating of the property binding from progessBar.value to canvas3d.progress run in the same thread.
The way to solve this problem is to call initializeGL() only for one step and then yield the CPU for updating the progress. My idea would be to use a single-shot timer that calls itself numSphere times and initialises the i-th spere in the i-th shot.
The step-wise initialisation function would be defined in test6.js as follows:
function initializeGLSphere(i) {
var x = list[i][0];
var y = list[i][1];
var z = list[i][2];
drawSphere(x,y,z,i);
}
After the instance of Canvas3d, you add the single-shot timer:
property int currentSphere = 0
Timer {
id: timer
repeat: false
interval: 0
onTriggered: {
GLCode.initializeGLSphere(currentSphere)
++currentSphere
progessBar.progress = currentSphere / GLCode.numSpheres
if (currentSphere < GLCode.numSpheres) {
timer.restart()
}
}
}
The timer is started in onInitializeGL:
onInitializeGL: timer.start()
Starting a single-shot timer means that an Event is put into the main Qt event loop. The timer fires once the timer interval expires. An interval of 0ms simply means that the timer fires and executes onTriggered as soon as possible the timer event reaches the front the event queue (loop).
In-between working on the timer events, the event queue will also give the QML engine some time to update the property binding for progressBar.progress. So, you should see quite a few intermediate progress values between 0 and 100. However, you will not see all because multiple timer events might be handled before a property-binding update happens. If you want to see more progress updates, you can simply increase the timer interval.
Related
I have a problem for tweening my camera.position . I create a codepen with the minimum of code just to reproduce my issue and I annotate all my code. I also put a lot of console.log() for debugging purpose .
Codepen
the start point is my camera.postion
camera.position.z = 30;
and my tween001
var tween001 = gsap.to(camera.position,{ delay:2,duration:5,z:60,onUpdate:function(){
camera.updateProjectionMatrix();
console.log("play");
},onComplete:function(){console.log("complete");},ease:"elastic"});
so the tween is about to move my camera from the Z = 30 to Z = 60
its work perfectly but ... When the user move the camera when the user move/over/click on the 3d its fire and eventlistener that pause "tween001.pause()" I want the tween001 use the "actual" camera.postion and not when the camera.postion used when the tween 001 get fire .
Cause when the tween001 is played again or it resume from a pause the start point used is the default one x=0 y=0 z=30 .
An idle function play the tween001 again
window.setInterval(checkTime, 1000);// every 1 second launch checktime()
function checkTime() { //idleCounter get 1 every second and at 5 second coz timeout is 5 checktime relaunch the tween001
if (idlecounter < timeout) {
idlecounter++;
//console.log("++ ");
} else if (idlecounter == timeout) {
tween001.play();
console.log('timeout');
}
}
So you have to understand that GSAP assumes it's the only thing that's controlling camera.position. So when you declare gsap.to(camera.position, {z: 60}) it'll store internally the starting position (30) and the ending (60) to build its timeline. It doesn't know that you've changed the z-position with the mousewheel, so when you call .play() it'll still assume you want to go from 30 to 60.
What you have to do is re-initialize a new tween each time so it has to look up the starting position when you want to replay it:
var tween001;
function doTween() {
tween001 = gsap.to(camera.position, { delay:2,duration:5, z:60, ease:"elastic", onComplete:function(){
// camera.updateProjectionMatrix();
console.log("complete");
}});
}
Notice that I declared var tween001 outside the function, in the global scope, so you can still call tween001.pause() whenever you need
There's no need to update the projection matrix while changing position.
Now, when you're ready to start the animation again, instead of using tween001.play() you can call doTween() and it'll build a new timeline that re-reads the camera's current z-position to start the animation:
// ...
else if (idlecounter == timeout) {
doTween();
idlecounter = 0;
}
see here for the updated codepen
This question already has answers here:
CSS transition doesn't start/callback isn't called
(3 answers)
Closed 2 years ago.
I have a dynamically created progress bar (Bootstrap) that is created ASAP on page load, inserted into the DOM and then it immediately starts progressing (the bar starts to fill up). This progress bar has a transition animation: when the bar's width increases (via JavaScript) it shall do so smoothly.
The progress comes in discrete steps: say 4 resources are retrieved asynchronously, when each one is loaded the progress bar increases 25 %.
The problem:
The loading of resources represented by the progress bar is sometimes very quick (I suspect there may be some caching involved). This results, sometimes, in the bar instantly changing width, completely skipping the transition animation and the subsequent ontransitionend event (because there was no transition). For a nice visual effect my code awaits the ontransitionend event, which means the code is stuck when this happens.
After painstaking debugging I narrowed it down to the following cause: The creation, insertion and the almost immediate full progression of the progress bar is so fast the bar hasn't even been rendered yet before it's over. As such, when the rendering do occur the bar is already "full" which means the animation is skipped, as the bar is rendered full directly.
Some pseudo code-ish examples (as the code is large and spread out).
main.js:
// Global variable
progressBar = createProgressBar();
await new Promise(function(resolve) {
// Await progress bar to fill up
progressBar.oncomplete(resolve);
// Let's say 4 resources
loadResources(function() {
// Callback function, invoked for each resource when it has loaded
// Additive 25 % increases for a total of 100 %
progressBar.progress(25);
});
});
// Finally, hide progressBar, show content
progress.js:
function createProgressBar() {
var completeCallback = function() {};
var percentage = 0;
var progressBar = ...; // Create element for progress bar
var parent = document.getElementById("progressBarContainer");
// Insert progress bar into DOM
parent.appendChild(progressBar);
// Register element transition event handler
progressBar.ontransitionend = function() {
if(percentage === 100)
completeCallback();
};
function oncomplete(callback) {
completeCallback = callback;
}
function progress(inc) {
percentage += inc;
progressBar.style.width = ( percentage + "%" );
}
return {
oncomplete: oncomplete,
progress: progress
};
}
This is essentially what happens, the progress() will be called 4 times before render and as such the bar starts full and no transitionend event is called.
I then used some google magic and found this article that showcased an example for how to wait for animation frames. I added the following code into the progress.js createProgressBar() body:
var loopCount = 0;
var observer = new MutationObserver(async function(mutations) {
// Await for two animation frames
await new Promise(function(resolve) {
function loop(){
window.requestAnimationFrame(function() {
loopCount++;
if(loopCount === 2) {
resolve();
} else {
loop();
}
});
}
// Start loop
loop();
});
// Trial and error, this code will now yield transition animation
progressBar.style.width = "100%";
observer.disconnect();
});
observer.observe(components.wrapper, { attributes: false, childList: true, characterData: false, subtree: true });
I tried awaiting one frame but I still had the same problem. In the example I await two frames, which seems to have done the trick as I can no longer reproduce the error. (That last piece kind of breaks the code before it as I set the width directly to produce the error.)
The question(s):
Am I right here, is the effect due to the rendering coming too late?
Secondly, is there another cleaner way to address this other than using MutationObserver and requestAnimationFrame or a timeout? I haven't been able to find an event for this unfortunately. While this solution works, i don't like the feeling of "picking" a number that works in case the error comes back.
Why don't you make pure HTML and CSS progress bar and control its state using js - changing class.
I have the following code which demonstrates the difference in calling a long-running function directly from an event trigger, vs. using setTimeout().
Intended behavior:
When the first button is pressed, it appears pressed, the calculation runs for several seconds, then when the calculation finishes, the button appears depressed again and the second column changes from "not calculating yet" to "calculation done". (I won't elaborate on why that is supposed to happen; it's explained in linked answer.)
When the second button is pressed, the button depresses immediately; the second column immediately changes to "calculating..." text. When the calculation finishes several seconds later, the second column changes from "calculating..." to "calculation done".
What actually happens:
This works perfectly in Chrome (both buttons behave as expected)
This works perfectly in Internet Explorer 8
This does NOT work in Firefox (v.25) as-is. Specifically, the second button behaves 100% as the first one.
Changing the timeout in setTimeout() from 0 to 1 has no effect
Changing the timeout in setTimeout() from 0 to 500 works
Which leaves me with a big conundrum.
According to the whole reason behind why setTimeout() works whereas lack of one doesn't, the delay should have zero effect on how things work, since setTimeout()'s main purpose is to change the queuing order here, NOT to delay things.
So, why is it not working with delay 0 or 1 on Firefox, but works as expected with delay 500 (and works with any delay on Internet Explorer 8/Chrome)?
UPDATE: In addition to source code below, I also made a JSFiddle. But for some reason JSFiddle refuses to even load on my Internet Explorer 8, so for that testing, the code below is required.
UPDATE2: Someone raised the possibility of there being an issue with configuration setting dom.min_timeout_value in Firefox. I have edited it from 4 to 0, restarted the browser, and nothing was fixed. It still fails with a timeout of 0 or 1 and succeeds with 500.
Here is my source code - I simply saved it to a HTML file on C: drive and opened in all three browsers:
<html><body>
<script src="http://code.jquery.com/jquery-1.9.1.js"></script>
<table border=1>
<tr><td><button id='do'>Do long calc - bad status!</button></td>
<td><div id='status'>Not Calculating yet.</div></td></tr>
<tr><td><button id='do_ok'>Do long calc - good status!</button></td>
<td><div id='status_ok'>Not Calculating yet.</div></td></tr>
</table>
<script>
function long_running(status_div) {
var result = 0;
for (var i = 0; i < 1000; i++) {
for (var j = 0; j < 700; j++) {
for (var k = 0; k < 200; k++) {
result = result + i + j + k;
}
}
}
$(status_div).text('calclation done');
}
// Assign events to buttons
$('#do').on('click', function () {
$('#status').text('calculating....');
long_running('#status');
});
$('#do_ok').on('click', function () {
$('#status_ok').text('calculating....');
window.setTimeout(function (){ long_running('#status_ok') }, 0);
});
</script>
</body></html>
To test, you will need to change the nested loop boundaries to 300/100/100 for Internet Explorer 8; or to 1000/1000/500 for Chrome, due to different sensitivity of "this JS is taking too long" error coupled with JavaScript engine speed.
There is a copy of the current (Jun 28, 2016) implementation of window.setTimeout() in Ubuntu.
As we can see, the timer gets inserted by this line of code:
nsAutoPtr<TimeoutInfo>* insertedInfo =
mTimeouts.InsertElementSorted(newInfo.forget(), GetAutoPtrComparator(mTimeouts));
Then a few lines below you have an if() statement:
if (insertedInfo == mTimeouts.Elements() && !mRunningExpiredTimeouts) {
...
The insertedInfo == mTimeouts.Elements() checks whether the timer that was just inserted already timed out. The following block does NOT execute the attached function, but the main loop will immediately notice that a timer timed out and thus it will skip the IDLE state (a yield of the CPU) that you are expecting.
This clearly (at least to me) explains the behavior you are experiencing. The rendering on the screen is another process (task/thread) and the CPU needs to be relinquished for that other process to get a chance to re-paint the screen. For that to happen, you need to wait long enough so your timer function does not get executed immediately and a yield happens.
As you've notice a pause of 500ms does the trick. You can probably use a smaller number, such as 50ms. Either way it is not going to guarantee that a yield happens, but chances are it will happen if the computer on which that code is running is not currently swamped (i.e. an anti-virus is not currently running full speed in the background...)
The complete SetTimeout() function from Firefox:
(location of the file in the source: dom/workers/WorkerPrivate.cpp)
int32_t
WorkerPrivate::SetTimeout(JSContext* aCx,
dom::Function* aHandler,
const nsAString& aStringHandler,
int32_t aTimeout,
const Sequence<JS::Value>& aArguments,
bool aIsInterval,
ErrorResult& aRv)
{
AssertIsOnWorkerThread();
const int32_t timerId = mNextTimeoutId++;
Status currentStatus;
{
MutexAutoLock lock(mMutex);
currentStatus = mStatus;
}
// It's a script bug if setTimeout/setInterval are called from a close handler
// so throw an exception.
if (currentStatus == Closing) {
JS_ReportError(aCx, "Cannot schedule timeouts from the close handler!");
}
// If the worker is trying to call setTimeout/setInterval and the parent
// thread has initiated the close process then just silently fail.
if (currentStatus >= Closing) {
aRv.Throw(NS_ERROR_FAILURE);
return 0;
}
nsAutoPtr<TimeoutInfo> newInfo(new TimeoutInfo());
newInfo->mIsInterval = aIsInterval;
newInfo->mId = timerId;
if (MOZ_UNLIKELY(timerId == INT32_MAX)) {
NS_WARNING("Timeout ids overflowed!");
mNextTimeoutId = 1;
}
// Take care of the main argument.
if (aHandler) {
newInfo->mTimeoutCallable = JS::ObjectValue(*aHandler->Callable());
}
else if (!aStringHandler.IsEmpty()) {
newInfo->mTimeoutString = aStringHandler;
}
else {
JS_ReportError(aCx, "Useless %s call (missing quotes around argument?)",
aIsInterval ? "setInterval" : "setTimeout");
return 0;
}
// See if any of the optional arguments were passed.
aTimeout = std::max(0, aTimeout);
newInfo->mInterval = TimeDuration::FromMilliseconds(aTimeout);
uint32_t argc = aArguments.Length();
if (argc && !newInfo->mTimeoutCallable.isUndefined()) {
nsTArray<JS::Heap<JS::Value>> extraArgVals(argc);
for (uint32_t index = 0; index < argc; index++) {
extraArgVals.AppendElement(aArguments[index]);
}
newInfo->mExtraArgVals.SwapElements(extraArgVals);
}
newInfo->mTargetTime = TimeStamp::Now() + newInfo->mInterval;
if (!newInfo->mTimeoutString.IsEmpty()) {
if (!nsJSUtils::GetCallingLocation(aCx, newInfo->mFilename, &newInfo->mLineNumber)) {
NS_WARNING("Failed to get calling location!");
}
}
nsAutoPtr<TimeoutInfo>* insertedInfo =
mTimeouts.InsertElementSorted(newInfo.forget(), GetAutoPtrComparator(mTimeouts));
LOG(TimeoutsLog(), ("Worker %p has new timeout: delay=%d interval=%s\n",
this, aTimeout, aIsInterval ? "yes" : "no"));
// If the timeout we just made is set to fire next then we need to update the
// timer, unless we're currently running timeouts.
if (insertedInfo == mTimeouts.Elements() && !mRunningExpiredTimeouts) {
nsresult rv;
if (!mTimer) {
mTimer = do_CreateInstance(NS_TIMER_CONTRACTID, &rv);
if (NS_FAILED(rv)) {
aRv.Throw(rv);
return 0;
}
mTimerRunnable = new TimerRunnable(this);
}
if (!mTimerRunning) {
if (!ModifyBusyCountFromWorker(true)) {
aRv.Throw(NS_ERROR_FAILURE);
return 0;
}
mTimerRunning = true;
}
if (!RescheduleTimeoutTimer(aCx)) {
aRv.Throw(NS_ERROR_FAILURE);
return 0;
}
}
return timerId;
}
IMPORTANT NOTE: The JavaScript instruction yield, has nothing to do with what I am talking about. I am talking about the sched_yield() functionality which happens when a binary process calls certain functions, such as sched_yield() itself, poll(), select(), etc.
I faced this issue with Firefox while toggling CSS classes using jQuery to control a CSS transition.
Increasing the duration of setTimeout to 50 from 0 helped, but as Alexis suggested this wasn’t 100% reliable.
The best (if longwinded) solution I found was to combine an interval timer with an IF statement to actually check whether the necessary styles had been applied before triggering the transition, rather using setTimeout and assuming execution had taken place in the intended order, e.g.
var firefox_pause = setInterval(function() {
//Test whether page is ready for next step - in this case the div must have a max height applied
if ($('div').css('max-height') != "none") {
clear_firefox_pause();
//Add next step in queue here
}
}, 10);
function clear_firefox_pause() {
clearInterval(firefox_pause);
}
In my case at least, this seems to work every time in Firefox.
In Firefox, the minimum value for setTimeout() calls is configurable and defaults to 4 in current versions:
dom.min_timeout_value The minimum length of time, in milliseconds,
that the window.setTimeout() function can set a timeout delay for.
This defaults to 4 ms (before 10 ms). Calls to setTimeout() with a
delay smaller than this will be clamped to this minimum value.
Values like 0 or 1 should behave like 4—no idea if that will cause delays in your code or just break it.
Context
I've got about 10 complex graphs which take 5sec each to refresh. If I do a loop on these 10 graphs, it takes about 50 seconds to refresh. During these 50 seconds, the user can move a scrollbar. If the scrollbar is moved, the refresh must stop and when the scrollbar stops to move, the refresh occurs again.
I'm using the setTimeout function inside the loop to let the interface refresh.
the algorithm is :
render the first graph
setTimeout(render the second graph, 200)
when the second graph is rendered, render the third one in 200ms, and so on
The setTimeout allows us to catch the scrollbar event and to clearTimeout the next refresh to avoid to wait 50sec before moving the scrollbar...
The problem is that it does not run anytime.
Take the simple following code (you can try it in this fiddle : http://jsfiddle.net/BwNca/5/) :
HTML :
<div id="test" style="width: 300px;height:300px; background-color: red;">
</div>
<input type="text" id="value" />
<input type="text" id="value2" />
Javascript :
var i = 0;
var j = 0;
var timeout;
var clicked = false;
// simulate the scrollbar update : each time mouse move is equivalent to a scrollbar move
document.getElementById("test").onmousemove = function() {
// ignore first move (because onclick send a mousemove event)
if (clicked) {
clicked = false;
return;
}
document.getElementById("value").value = i++;
clearTimeout(timeout);
}
// a click simulates the drawing of the graphs
document.getElementById("test").onclick = function() {
// ignore multiple click
if (clicked) return;
complexAlgorithm(1000);
clicked = true;
}
// simulate a complexe algorithm which takes some time to execute (the graph drawing)
function complexAlgorithm(milliseconds) {
var start = new Date().getTime();
for (var i = 0; i < 1e7; i++) {
if ((new Date().getTime() - start) > milliseconds){
break;
}
}
document.getElementById("value2").value = j++;
// launch the next graph drawing
timeout = setTimeout(function() {complexAlgorithm(1000);}, 1);
}
The code does :
when you move your mouse into the red div, it updates a counter
when you click on the red div, it simulates a big processing of 1sec (so it freezes the interface due to javascript mono thread)
after the freezing, wait 1ms, and resimulate the processing and so on until the mouse move again
when the mouse move again, it breaks the timeout to avoid infinite loop.
The problem
When you click one time and move the mouse during the freeze, I was thinking that the next code that will be executed when a setTimeout will occurs is the code of the mousemove event (and so it will cancel the timeout and the freeze) BUT sometimes the counter of click gains 2 or more points instead of gaining only 1 point due to the mouvemove event...
Conclusion of this test : the setTimeout function does not always release resource to execute a code during a mousemove event but sometimes kept the thread and execute the code inside the settimeout callback before executing another code.
The impact of this is that in our real example, the user can wait 10 sec (2 graphs are rendered) instead of waiting 5 seconds before using the scrollbar. This is very annoying and we need to avoid this and to be sure that only one graph is rendered (and other canceled) when the scrollbar is moved during a render phase.
How to be sure to break the timeout when the mouse move ?
PS: in the simple example below, if you update the timeout with 200ms, all runs perfectly but it is not an acceptable solution (the real problem is more complex and the problem occurs with a 200ms timer and a complex interface). Please do not provide a solution as "optimize the render of the graphs", this is not the problem here.
EDIT : cernunnos has a better explanation of the problem :
Also, by "blocking" the process on your loop you are ensuring no event can be handled until that loop has finished, so any event will only be handled (and the timeout cleared) inbetween the execution of each loop (hence why you sometimes have to wait for 2 or more full executions before interrupting).
The problem is exactly contains in bold words : I want to be sure to interrupt the execution when I want and not to wait 2 or more full executions before interrupting
Second EDIT :
In summary : takes this jsfiddle : http://jsfiddle.net/BwNca/5/ (the code above).
Update this jsfiddle and provide a solution to :
Mouse move on the red div. Then click and continue moving : the right counter must raise only once. But sometimes it raises 2 or 3 times before the first counter can run again... this is the problem, it must raise only once !
The BIG problem here is setTimeout is unpredictable once it started, and especially when it is doing some heavy lifiting.
You can see the demo here:
http://jsfiddle.net/wao20/C9WBg/
var secTmr = setTimeout(function(){
$('#display').append('Timeout Cleared > ');
clearTimeout(secTmr);
// this will always shown
$('#display').append('I\'m still here! ');
}, 100);
There are two things you can do to minimize the impact on the browser performance.
Store all the intances of the setTimeoutID, and loop through it when you want to stop
var timers = []
// When start the worker thread
timers.push( setTimeout(function () { sleep(1000);}, 1) );
// When you try to clear
while (timers.length > 0) {
clearTimeout(timers.pop());
}
Set a flag when you try to stop process and check that flag inside your worker thread just in case clearTimeout failed to stop the timer
// Your flag
var STOPForTheLoveOfGod = false;
// When you try to stop
STOPForTheLoveOfGod = true;
while (timers.length > 0) {
clearTimeout(timers.pop());
}
// Inside the for loop in the sleep function
function sleep(milliseconds) {
var start = new Date().getTime();
for (var i = 0; i < 1e7; i++) {
if (STOPForTheLoveOfGod) {
break;
}
// ...
}
}
You can try out this new script.
http://jsfiddle.net/wao20/7PPpS/4/
I may have understood the problem but assuming you are trying to block the interface after a click for a minimum of 1 second and unblocking it by moving the mouse (after that 1 second minimum):
This is not a good implementation of sleep, as you are keeping the process running the whole time (doing nothing != sleeping), this results in a waste of resources.
Why not create an overlay (a semi/fully transparent div), put it on top of the rest of the interface (position fixed, full width and full height) and use it to prevent any interaction with the underlying interface. Then destroy it when the conditions are right (a second has passed and the user moved the mouse).
This behaves more like a sleep (has some initial processing time but then releases the processor for a given amount of time) and should help you achieve the behavior you need (assuming i understood it right).
It has the added bonus of allowing you to give the user some visual cue that some processing is being done.
Edit:
Also, by "blocking" the process on your loop you are ensuring no event can be handled until that loop has finished, so any event will only be handled (and the timeout cleared) inbetween the execution of each loop (hence why you sometimes have to wait for 2 or more full executions before interrupting).
Surprising enough you have not figured out that, when you setTimeout(); you can input a check after that. A variable is true then trash the wait, or trash it. Now there is a method that you can check to scroll with a scroll bar. After you have checked it true inside a variabled using the means, then you will find this will repeat inifite times as they scroll the bar, making many executing times of 5 seconds. To fix this add a 1 second wait to make sure it doesn't over repeat. Your welcome :)
Any long-running function is going to tie up your browser window. Consider moving your complexAlgorithm() outside of your main javascript code using WebWorkers.
The answer is in your question
...the refresh must stop and when the scrollbar stops to move, the
refresh occurs again.
You should write complexAlgorithm in such way that you can almost instantly brake it in a middle (just when you know you will have to re run)
so main code should look something like
stopAllRefresh; //should instantly(or after completing small chunk) stop refresh
setTimeout(startRefresh, 100);
and render graph in small chunks (each runs < 1sec) in setTimeout
like
var curentGraph = 0;
var curentChunk = 0;
function renderGraphChunk(){
if (needToBreak) //check if break rendering
{exit};
// Render chunk here
render(curentGraph, curentChunk);
curentChunk +=1;
setTimeout(renderGraphChunk, 1);
}
this is just a idea sketch, real implementation can be completely different
What you want to do can not be done without web worker, that is only implemented in some latest browser specially Chrome.
Otherwise, you have to break your algorithm in queue. Just like jQuery UI puts every next animation calculation in queue. http://api.jquery.com/jQuery.queue/
It is a simple queue and next instruction set is queued with help of setTimeout.
for (i=0; i <1000; i++)
{
process (i) ;
}
Can be translated to
function queue(s,n, f)
{
this.i=s;
this.n=n;
this.f=f;
this.step = function(){
if ( this.i <this.n)
{
this.f(this.i);
this.i = this.i +1;
var t = this;
setTimeout( function ( ) { t.step(); } , 5);
}
}
this.step();
}
queue ( O, 1000, function(i){
process(i);
}) ;
This is just an example of how Synchronous for loop can be written to execute same logic asynchronously using smaller independent iteration.
Try and check out web workers. I think it will be useful in this situation.
http://en.wikipedia.org/wiki/Web_worker
http://www.html5rocks.com/en/tutorials/workers/basics/
I have a div displaying some horizontally scrollable images with white-space:nowrap; overflow-x:scroll and i'm trying to make the function below work:
var mouseIsInDiv = false;
function autoScroll() {
var i = 1;
while (mouseIsInDiv = false) {
setTimeout(function(){
document.getElementById("theDiv").scrollLeft = i;
i++;
},50);
}
}
It is supposed to loop through (while the mouse is not within this scrollable div) incrementing the scroll position by 1px every 50 miliseconds. In other words it's supposed to scroll through the images automatically when this function is called. I'm not getting any syntactic errors but whenever i press a button that calls this function on a webpage, the browser crashes completely - I'm using the latest versions of Chrome, Safari and Firefox. Any ideas would be really helpful, I've been tearing my hair out over this!
Your loop creates many timeouts that happens in the same time (after 50 milisecs) you need to set the timeout recursivly, inside the set timeout function, and ask if mouseISInDiv inside the set timeout function as well.
The current code state, the loop will run many many times in a small amount of time, and page will crush(it's liek infinite) and after 50 millisecs there will be many set timeouts that ran.
I had a fun time working on this one, so I'll post my response despite the correct answer already having been accepted.
Basically, you need to restructure everything so that the whole scheme is asynchronous. That means event listeners respond to mouse movement, and there are no while loops.
Thus, I present this fiddle. Here is the javascript:
var mouseIsInDiv = false;
var theDiv = document.getElementById("theDiv");
theDiv.onmouseover = function() { mouseIsInDiv = true; };
theDiv.onmouseout = function() {
mouseIsInDiv = false;
scrollLeft1();
};
function scrollLeft1() {
if (mouseIsInDiv == false && theDiv.scrollLeft < theDiv.clientWidth) {
theDiv.scrollLeft += 1;
setTimeout(scrollLeft1, 50);
}
}
scrollLeft1();
As you can see, the function calls itself recursively and asynchronously, and the whole thing can be restarted after manually resetting the scroll. You could also add an event listener for the scroll completion.