RhinoApp.Wait() slowdown

i have a command, running in a kind of "game loop",

the update happens with doc.Views.Redraw() and RhinoApp.Wait()

the thing is - what specifies the framerate? Because i noticed if i am in "orbit-mode" (right mouse button) the whole loop speeds up by 200%+..

is there any other way to keep the windows alive and increase the update rate?

▶ Reply to This

Replies to This Discussion

Permalink Reply by Dale Fugier on February 4, 2013 at 9:16am

Hi Damjan,

Can you explain, in detail, what you are trying to do and what is not working? What you have provided does not give me enough information to make any suggestions.

Thanks,

-- Dale

▶ Reply

Permalink Reply by damjan fio on February 4, 2013 at 1:01pm

ok sorry, for example:

protected override Result RunCommand(RhinoDoc doc, RunMode mode)
        {
            RhinoApp.WriteLine("Test. {0}",DateTime.Now);
            do
            {
                doc.Objects.AddPoint(new Point3d(r.NextDouble() * 10.0, r.NextDouble() * 10.0, r.NextDouble() * 10.0));
                doc.Views.Redraw();
                RhinoApp.Wait();
            } while (!exit);
            return Result.Success;
        }
    }

this adds random points, and updates the viewport, but if you start to orbit the view while the command is running, it suddenly loops much faster.

my question is just, is there a way to control the update speed / wait duration (i guess now its 60hz? - vsync?)

i can live without having control over this (and instead update with a tick event or something..), but if it is possible, please let me know.

thanks

▶ Reply

Permalink Reply by Dale Fugier on February 6, 2013 at 10:45am

> my question is just, is there a way to control the update speed / wait duration

Sorry, no.

-- Dale

▶ Reply

Permalink Reply by damjan fio on February 8, 2013 at 4:51am

do you maybe have any other suggestion how i can have just the active viewport redraw + orbit control? - i just measured the time of an action - 18 seconds vs. only 3 seconds if i orbit the view.. (i guess even if i could force the orbit view, there would be the problem that i cant access my usercontrol anymore)

▶ Reply

Permalink Reply by Dale Fugier on February 8, 2013 at 1:27pm

I still don't know (fully) what you are trying to do (other than add some points to Rhino). More explaination (fully) would be helpful. Otherwise, I'm not sure I can help.

-- Dale

▶ Reply

Permalink Reply by damjan fio on February 8, 2013 at 7:40pm

e.g. i imported a physics library and managed to make a box bounce around the xy-plane (drawing with displayConduit)

now this runs for 500 loops, which is 18 seconds, if i redraw+wait every loop.

If i start to orbit the view while the command is executing, the whole simulation finishes in 3 seconds (box bouncing much faster)

So i figure its not the redraw slowing it down (which doesn't redraw unless the 'wait' comes in), but something else, which is not active when the orbit mode is triggered.

I want to use Rhino to carry out some realtime stuff, and right now this 'wait' thing is severely slowing down things. Hope its clear, and there is a way to overcome this..

btw. the Sample you gave me regarding the classes problem, helped a lot - i am starting to remember/learning the concepts behind OO programming - thanks!

▶ Reply

Permalink Reply by Dale Fugier on February 13, 2013 at 4:02pm

It’s hard to tell where the bottleneck is, or why orbiting the view speeds up your loop. I’m not seeing in your example how the loop even stops.

But. You are updating ALL views in your loop, whereas orbiting will only update the active view. Why don' you get a hold of the active view and redraw it instead? I’m not sure if pipelines and methods are accessible from what you doing, but the fastest way to get a viewport to update is (C++):

dp.DrawFrameBuffer(….)
dp.ShowFrameBuffer(…)

Noth will interrupt that, and is pretty much what things like the Spin command do.

If you have a simple example (full program), I’d be glad to step through it and see where the hang-ups are.

-- Dale

▶ Reply

Permalink Reply by damjan fio on February 18, 2013 at 10:37am

i think i found the source of the problem - its the Cplane/World Panel in the lower left corner. If i move the mouse fast while a command is running (screen refreshing) it slows down alot, as the cplane numbers get updated. If the mouse is stationary it get better, but still - while orbiting the cplane info is suspended - and then it loops supersmooth.

Is there a way to deactivate this - or maybe override it?

i will try to create a small sample plugin that shows the problem