Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: mysterious delay in output

  1. #1
    Member Contributor
    Join Date
    Feb 2009
    Posts
    73

    mysterious delay in output

    I just came back to doing 3D stuff after a hiatus of six months or so, because of an idea I had one day.

    So I spent about a day putting that idea together, using stuff I'd previously coded as a guideline, because all that works fine.

    Now here's the problem: there is a significant and noticable delay between when the code is being executed and when it is rendered, almost a full second. I don't have very good frame rates (25-25 fps), but that is not the problem: the problem is, if I (for example) move the mouse, hit a key, etc, this event is logged IMMEDIATELY on the console (via printf) but in the OGL window, it does not occur for a noticable delay -- so noticable, I can move the mouse quickly for say 1/2 second and the display doesn't start moving til my hand is off it. Parallel to this, if I put a condition in to flash an object red every few hundred frames and count ticks in the console, the object actually flashes about 15-20 frames AFTER the code has been executed, going by the console output (nb -- please, don't bother me w/ remarks about this methodology).

    Now, here's the clincher: my old code, that I used as the template for my new code, does not have this issue at all. Console output and the display are perfectly syncronized, I can move the mouse and there is no delay, etc. The only difference between the two is that the old code uses lighting and texture, whereas I have not added that to the new code yet.

    Anyone have any idea why this could happen -- that is, how I would end up with the display lagging 15-20 frames behind the execution?

  2. #2
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    Perhaps you use a non hardware accellerated driver ?


    @+
    Yannoo
    @+
    Yannoo

  3. #3
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    No, this cannot be the case because your framerate haven't to be biggly reduced ...

    What driver use you ?
    It's the same case with an software emulation driver ?
    (ok, the framerate isn't the same but this can perhaps give indications about the thing that make this delay)

    @+
    Yannoo
    @+
    Yannoo

  4. #4
    Member Contributor
    Join Date
    Feb 2009
    Posts
    73

    Re: mysterious delay in output

    Well, there no GPU -- it's an onboard via chrome.

    Also, it's linux, so I'm using software emulation courtesy of X windows.

    However, I don't think that is the issue, as I said most of the stuff I have written does not have this problem. But that stuff is all "complete", with lighting and textures. I don't recall having noticed it prior to that, but I wasn't approaching it with as much attention when I was first learning. Beyond the lack of texture, there is not difference in the implimentation AFAICT -- I use a timer, I use gluLookAt for the perspective, etc. I have no idea why this should happen or how, considering it is not flat out limitation on the system.

    I suppose I could just add texture and stuff until it really is identical, and see -- but my plan was to work most of the details out just with simple colors first, so I'd prefer not to if I can find some explanation.

  5. #5
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    This exactely the same code, but without texture use ???

    If yes, why don't create an unused texture and test with and without it ?

    @+
    Yannoo
    @+
    Yannoo

  6. #6
    Member Contributor
    Join Date
    Feb 2009
    Posts
    73

    Re: mysterious delay in output

    Hey, I updated my last post while you were replying (vis why I don't want to add texture yet).

    They are not totally identical -- the first one is just a scene where I can navigate the camera around. The new one, the scene is different (much simpler so far; I don't want to proceed until I get this straightened out) and the nature of the camera movement is different. I want it to move in x and y but not z, and be aimed straight on the z axis . It is, just the whole thing has a one second delay.

    I guess I could take my other project and take the texturing out to see if that matters. I already tried turning the lighting off:

    Code :
            if (LIT) {
                    glEnable(GL_LIGHTING);
                    glEnable(GL_NORMALIZE);
                    glColorMaterial(GL_FRONT,GL_AMBIENT_AND_DIFFUSE);
                    glEnable(GL_COLOR_MATERIAL);
                    glLightfv(GL_LIGHT0,GL_SPECULAR,Specular);      
                    glEnable(GL_LIGHT0);
                    arrangelamp();
            }

    all the determination of the normals is left in anyway. It still works fine.

    And the mechanism is the same. I'm using glut, so the frames are turned over with glutTimerFunc. In the new one, I initially wrote it without a timer, using glutPostRedisplay(), since I figured that would maximize the frame rate (it doesn't -- they come out the same) then switched it to this method hoping that would help.

    The camera movement is slightly different (the camera in the first one rotates around y, and moves up and down, and it's distance from the origin is manipulable, so it's potential path is like a dynamically resizable cylinder), but again, the method is just to modify some global values based on input device events.

    Maybe worth noting: initially I tried SDL for the second one, and had the exact same problem, so I thought it was SDL and switched back to glut, which I like better anyway. But the delay is still there.

  7. #7
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    Have you test with glDisable(GL_LIGHTING) when if (LIT) is false ?

    Have you disabled the texturing ?



    @+
    Yannoo
    @+
    Yannoo

  8. #8
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    You can perhaps display the time before and after glutPostRedisplay for to see ?

    @+
    Yannoo
    @+
    Yannoo

  9. #9
    Member Contributor
    Join Date
    Feb 2009
    Posts
    73

    Re: mysterious delay in output

    Quote Originally Posted by Yann LE PETITCORPS
    Have you test with glDisable(GL_LIGHTING) when if (LIT) is false ?
    Yes, I added an else clause for that -- altho since in that case the lighting is never enabled, it should not matter.

    Have you disabled the texturing ?
    No, not in the first one -- the scene is fairly complex, with a lot of texture. But I just added a texture to the second one, still the same problem.

    Quote Originally Posted by Yann LE PETITCORPS
    You can perhaps display the time before and after glutPostRedisplay for to see ?
    I am not using glutPostRedisplay() -- the scene is redrawn using glutTimerFunc():

    Code :
    void nextick (int num) {
            drawScene();
            glutTimerFunc(1,nextick,num+1);
    }
    I have also coded it without this, using glutPostRedisplay() at the end of drawScene(), the outcome is exactly the same. Evidentally, glutTimerFunc() does not fork the function it calls, ie, drawScene() does not really get called 1000 times per second. It gets called the same number of times that it would using glutPostRedisplay() to depend on the main loop. It amounts to the same thing, except I can use nextick() as a set-up for drawScene(). In any case, my method there does not make a difference to the problem.

    It was printing debugging info (such as time and fps calculations) in drawscene that made me realize the delay is between execution and rendering. It is taking place somewhere in the GL call stack, after my code has executed.

    I have a simple block in drawscene to demonstrate this, here's a pseudo-code version:
    Code :
    set drawing color black
    every 500 frames:
         printf("NOW\n");
         change drawing color to red
    every frame:
         printf("*";
    So, NOW should appear in the console simultaneous to the object flashing red. That doesn't happen. If I wait and interrupt the execution when I see the red flash, I get:

    NOW
    ***********************************^C


    If the display were simultaneous, there would only be <6 asterisks there, since my response time is not perfect. However it is not nearly this slow! And as I've said, this delay is very, very apparent. With my earlier project the display responds immediately to the mouse. With my current one, this delay is so bad as to make using the application very awkward.

  10. #10
    Senior Member Regular Contributor
    Join Date
    Nov 2009
    Location
    French
    Posts
    117

    Re: mysterious delay in output

    Have you test with a printf("*\n") in each frame (stdio output can be "cached" by example)

    @+
    Yannoo
    @+
    Yannoo

Page 1 of 2 12 LastLast

Similar Threads

  1. Mysterious vertices after scece is rendered
    By rpodhajny in forum OpenGL ES
    Replies: 1
    Last Post: 01-26-2011, 10:50 PM
  2. Replies: 7
    Last Post: 05-20-2010, 07:28 AM
  3. Shoemake's Mysterious Translation Controller
    By Steven Katic in forum OpenGL: General
    Replies: 0
    Last Post: 09-14-2008, 04:21 PM
  4. Mysterious source of instability
    By erik-k in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 09-23-2004, 02:14 PM
  5. really mysterious gl_TexCoord[0] in fragment shader
    By andreasMank in forum OpenGL: GLSL
    Replies: 5
    Last Post: 05-27-2004, 12:47 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean