javascript interrupt / progress bar / performance
I made a javascript that generates a matrix of points.
The script does the computation of the colorcode of each point.
The good news is that it works.
The javascript itself is ready within one second.
However, GeoGebra needs time to process all geogebra commands.
When someone presses the actionbutton, he has to wait.
During processing, GeoGebra does not show every new point.
GeoGebra does a refresh afterwards when the whole script is ready.
So, the user has to wait and wait and wait ...
So that the user sees that his computer is progressing slowly.
People ask me about an stop button to interrupt the javascript.
Is there a possibility
- to show the build up?
- to interrupt
- to show the progress the script knows the actual progresss
- to estimate the remaining time
How can I achieve this ?
The javascript processes point after point and invokes API's for every point.
Is there a way to speed things up?
https://www.geogebra.org/m/zhjwgc4u
Yours sincerely,
Henk Hietbrink
JavaScript is single-threaded so this isn't possible (unless you can split the task up into small chunks)
Dear Michael,
Of course, I tried a lot of things, like adding an actionbutton or a boolean, but it seems that they are suspended until the running script has finished. So, my question is which event might run parallel code?
What is your suggestion to split it into small chunks?
One of my tests was to check the status of a variable and quit the loops when set
if (ggbApplet.getValue("stop")>0) {
var num = prompt("quit",0)
s_x = limit_s + 1
s_y = limit_s + 1 }
Another question is about screen updating.
I would like that users see that the program is working
Can you use a GeoGebra slider to trigger the different actions?
Cleer idea,
Unfortunately, the code exists of three loops
One is to calculate the eclipse itself: that is one javascript array
Two is to compute the points with the absolute number of hits: that is another javascript array
In the mean while, it computes the maximum number of hits
Three is to create all the points each with its specific color, being the relative number.
It is no good to do steps one and two for each and every point.
It seems that there is no possibility to define global arrays that remain in memory.
That would help to perform step three step by step
It is generally a bad idea to draw a lot of points at the same time in GGb.
It is mostly smarter to use a trace/sweep line approach and use one of the neat features of GGb.
The ability to have remaining traces on the canvas.This reduces the points/lines/objects needed and allows chunking a computation.
But in this case it might be difficult as you have greedy algorithm.
You could construct a point projection with opacity and superimpose the resulting images (sadly GGb can not create opaque traces of inequalities).
Or you could create sampling points on the source image and the aperture.
Those points can be used to interleave a construction of projected points which can be used to construct opaque elements like circles or rectangles.
But this has its limits as GGb is not a tool for those kind of tasks.
That is the reason i graduated from using GGb heavily.
You could also use a faster program/tool like a shader based approach.
Here an example which could be expanded with further interactivity.
Quote Loco: "You could construct a point projection with opacity and superimpose the resulting images (sadly GGb can not create opaque traces of inequalities)."
Same idea as Loco but with polygon instead of inequality.
Thanks for the idea.
It solves a lot of problems/I let you know.
When I publish, I would like to give credits to those who helped.
Who are you?Do you have a website?
This is me: Henk Hietbrink and this too Frans van Schooten
Thanks for your help.
I made an update to same address https://www.geogebra.org/m/zhjwgc4u
Thanks for support,
Henk Hietbrink
Two further Ideas.
If you are only interested in the outer bounds you could use signed distance fields.
To realize them you can either use a numerical approach (get the outer bounds of the (0,0) projected image and get the closest distance to that) or an analytical approach where you calculate the distance on each possible point in space to the outer bounds.
You can use those results in order to build the image via sweep points (GGb colored images via point traces). In combination with an value offset you can thicken the (0,0) image to the outer bounds created by the aperture radius.
Another one is calculate/construct the (0,0) image and construct/calculate the thickened outer bounds.
Both will give you the image area where light can land.
The first approach might be possible in GGb but it will push the limits quite a bit.The second is a bit tedious but the recommended GGb way (if you want only the outer bounds).
I gave up annoyed that GGb does not allow to draw ellipse inequalities of general ellipses
I updated the shader example. It demonstrates now what i might have aimed with GGb.
It allows to preview the resulting image while changing the aperture and moon radius on the fly.
And afterwards have a approximated simulation of how the image light might be distributed.
Sure, the colour distribution could be adapted to non RGB values to reflect the image our eyes might see.
As for the credits you want to give. If you use the shader you can put my name somewhere (do not have a webpage).
For the ideas or the GGb stuff... i do not need credits for that it was merely to see if i can still do it.
Give the credits to rami.
Comments have been locked on this page!