I know this is a long shot but I have a problem.
The code I’ve been working on that uses Xith has a jump. A periodic delay up to .2 seconds. It occurs about once every 1 to 10 seconds. However I have an old Xith build that if I plug that into my code, the jump goes away. I don’t know when exactly the build was compiled, but the files inside the jar are all dated 8/19/2005 6:21 pm. Any one seen anything like this or know or have a guess whats wrong?
I see the jump too, well since long time now really (since 2 releases back I think, and current CVS version does the same), but I was always thinking it is something in my code causing that, but since it is not disturbing me much I never tried to find out what is that exactly. You will not notice that on fast computers but on avarage one (800MHz CPU / TNT2 videocard as in my case) and especially when the scene is pretty heavy - yes I can confirm that something like this exists for me too, short and periodic hick-ups.
But again - it maybe my problem somewhere, though I doupt to say true…
Edit: and for what it could be… well, I guess you see garbage collector work…
Bohdan.
BTW, here I made little demonstration for these things:
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import javax.swing.JFrame;
import javax.vecmath.Point3f;
import javax.vecmath.Vector3f;
import org.xith3d.test.util.TestUtils;
import com.xith3d.render.CanvasPeer;
import com.xith3d.render.RenderPeer;
import com.xith3d.render.jsr231.RenderPeerImpl;
import com.xith3d.scenegraph.BranchGroup;
import com.xith3d.scenegraph.Canvas3D;
import com.xith3d.scenegraph.Geometry;
import com.xith3d.scenegraph.Locale;
import com.xith3d.scenegraph.Shape3D;
import com.xith3d.scenegraph.Transform3D;
import com.xith3d.scenegraph.TransformGroup;
import com.xith3d.scenegraph.View;
import com.xith3d.scenegraph.VirtualUniverse;
public class HickUpTest {
public HickUpTest() {
JFrame frame = new JFrame("HickUps Test");
frame.setSize(500, 500);
//======= setting up Universe ===============
VirtualUniverse My_Universe = new VirtualUniverse();
Locale locale = new Locale();
My_Universe.addLocale(locale);
BranchGroup scRootBG = new BranchGroup();
locale.addBranchGraph(scRootBG);
//------------------------------
RenderPeer renderPeer = new RenderPeerImpl();
CanvasPeer canvasPeer = renderPeer.
makeCanvas(frame.getContentPane(), 0, 0, 32, false);
Canvas3D scrCanvas = new Canvas3D();
scrCanvas.set3DPeer(canvasPeer);
//------------------------------
View scView = new View();
scView.addCanvas3D(scrCanvas);
My_Universe.addView(scView);
//======== adding many shapes3d ===============
TransformGroup TG;
Transform3D tf;
for (float i = -30; i < 30; i++) for (float j = -30; j < 30; j++) {
Geometry geom = TestUtils.createSphere(0.2f, 10);
tf = new Transform3D();
tf.setTranslation(new Vector3f(i, j, 0));
TG = new TransformGroup(tf);
TG.addChild(new Shape3D(geom));
scRootBG.addChild(TG);
}
//======= running =============================
frame.setVisible(true);
scView.getTransform().lookAt( new Point3f (0, 2, 2),
new Point3f (0, 5, 0),
new Vector3f(0, 0, 1));
//---------------------------------------------
int N = 1000;
long[] dTs = new long[N];
int i = 0;
long currTime,
lastTime = System.currentTimeMillis();
while (i < N && frame.isVisible()) {
scView.renderOnce();
//-----------------------------------
currTime = System.currentTimeMillis();
dTs[i++] = currTime - lastTime;
lastTime = currTime;
}
//---------------------------------------------
File outputFile = new File("out.dat");
try {
outputFile.createNewFile();
BufferedWriter out = new BufferedWriter(new FileWriter(outputFile));
for (int j = 0; j < N; j++) out.write(dTs[j] + "\r");
out.close();
} catch (IOException e) {};
//---------------------------------------------
System.exit(0);
}
public static void main(String args[]) {
new HickUpTest();
}
}
So nothing is dynamically modified in that example, but still you see those delays somethimes.
Difficult to judje really on it, it might be some system interferiences… but this is really simple test (just heavy a bit). If to try and dig further maybe more specific problems could be seen.
An avarage deviation of hickup-delay from an avarage frame rendering time is about 30%, and this is something that can be noticeable I think…
I’ve used -verbose:gc to print out each garbage collection and the time taken and it doesn’t seem to corespond to the hick-ups. The GC runs about 3 or 4 time as often as the hick-ups and doesn’t vary is length. But I’d encurage you to give it a try and see if I’m mistaken.
As to systems. I’m running on 2.0 GHz CPU / ATI Radion Mobile x300 / 1GB RAM
hmmm… if not GC what would it be?.. the test posted above is totally “static”… were these delays are comming from then? Ok, I will try too, to check precisely with GC too.
Yep… you are right, I checked it as well, and I don’t see any corespondence too. BTW I run that test many times and actually the “shots” of hick-ups are often much higher then 30%… and no GC intervention really…
Anybody what is that ??? Any idea?
Another thing. I believe I observed that the hick-ups were more prominent when the mouse was waved over the window and the window is in focus, compared to the window being in foucs and the mouse not moving. And the the hick-up was less prominent when the window was not in focus compared to the window being in focus. This would lead me to guess that there is a static mouse motion listener in Xith somewhere. I haven’t run any tests yet to verify these observations.
Well, I doupt it very much… Xith is scenegraph & renderer but doesn’t handle any input events. If you want to you have to do that “outside”. For examle you use JPanel which xith is rendering to, to add any listeners then you have input. But there are no “hidden” listeners, and I don’t think there are any means for that at all.
This what you see in regards to mouse & focus, is probably different thing. Any focused window will receive events, events queue will be populated, dispatched and processed at leats somehow “by default” even if there are no listeners and again it is something “outside”. You can create your java.awt.EventsQueue and push it instead default one - and you will see all those events hanging around and you can even block them on higher level, so you application will never get them even if you have listeners. But they always exists.
What I mean by this - if you don’t do anything “extra” - then this process of dispatching and processing events always exists and of course will take some of your CPU time. If you hovering mouse intensively over your application window - you should expect slowing down… Same if you hovering mouse at all somewhere even not over your window - some CPU time going to be spent on this.
You probably have run benchmarks on your PC, and what they say? - “don’t touch your mouse” :), so this is somehow intensive operation sometimes…
This that symptoms of hick-ups are somehow afected when you generaly loading CPU (with the mouse motion for instance) - this is probably something expected…
When I was running the test above - I didn’t touch PC at all, just left it in peace, but I still have seen those delays - and now, under this condition - this is very strange to me…
Another possibility is the frequent claims that the standard vectoe/math jar creates oddles of garbage variables. There are some recent comments (william I think) on an alternate jar that is less garbage creating.
bohdan, I was simply pointing out a correlation. I have an older jar (Which I’d be happy to post online if any one would be interested), and it doesn’t have any hick-ups, so we know its either Xith or perhapse JOGL. Perhaps the mouse movement simply slows everything down, or perhapse it increases the hick-ups more than the rest of the cycles. I would suggest you run the test with both. I will also do it myself, once I get some time to spare.
hawkwind, vecmath garbage could be the problem, but there appears to be no correlation between the garbage collections and the hick-ups. However if you could provide a link to the alternate jar, I believe we’d be happy to try the tests with and with out it.
You are ok, Patheros :). Sorry, I didn’t meant to argue, just was putting my thouths accross. My english is poor, so sometimes it might looks like I’m arguing or smth… 
What about mouse - honestly, I would not consider this at the moment, because those hick-ups do exist without any mouse intervention or input events as well. After we found what causes it, sort it out or just except that “this is normal”, then we can disscuss input events if needed, but at the moment things happening without any input events too - and this is something interesting…
[quote="<MagicSpark.org [ BlueSky ]>,post:11,topic:27832"]
It was Yuri who mentioned that. Here it is : http://objectclub.esm.co.jp/vecmath/
[/quote]
Ok… but it seems like (well, proven really) GC has nothing to do at least with the test case posted above. GC simply never or really seldom runs in comparison to number of hick-ups happenning. So maybe here are 2 different things to consider:
- the actually garbage collection
- no garbage collection yet but frequent “extra memory” allocation by JVM (probably you mean that?) - this can be the cause of hick-ups. Extra memory allocation might be more frequent (well, I am sure it is) then GC…
Bohdan.
I don’t want to argue either. And thank you bohdan, you’ve put a lot of effort into this and I appreciate it.
As to vecmath being the cause. I just visually tested it and it doesn’t appear to fix it, but I’d still encurage you to test it also. Also, it is missing TexCoord4f, which the TriangleArray uses in its setTextureCoordinates method. Of course it wouldn’t be hard to add it, if it was decided that the rest of the jar actually helped.