Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redraws Cannot Be Synchronized #4

Open
ShadSterling opened this issue Jul 28, 2012 · 4 comments
Open

Redraws Cannot Be Synchronized #4

ShadSterling opened this issue Jul 28, 2012 · 4 comments

Comments

@ShadSterling
Copy link

Originally reported in the Tracker on the SourceForge project, 2000-Dec.-27, http://bit.ly/SZfe3U

Without synchronizing redraws, the user will see partially updated scenes, likely in an incoherent state.
This makes vpython unusable for animated scenes with nontrivial computation per frame, which includes everything I intended to use it for.

I would like to be able to do something like this:

scene.autoredraw = false # disable unsynchronized redraws
while myUpdate( scene ):
    scene.redraw( minInterval ) # synchronized redraw between updates

The original reporter suggested this:

while 1:
    visual.stop() # suspend the visualization thread
    doMyCalculations()
    visual.start() # resume the visualization thread
    visual.rate(30)

For one easy to see example of the problem:
Run my code at http://pastebin.com/srsZLKWR and make it continuously advance (by clicking on a blue arrow, dragging the mouse, and then holding the button down).
On my computer you can see the particles update before the field arrows, and you can watch the updating of the field arrows propagate through the field.
I can't tell how much time is spent updating the scene and how much time is spent drawing intermediate states that are not intended to be seen, but I expect eliminating the unnecessary redraws would improve performance as well as prevent drawing incoherent states.

@BruceSherwood
Copy link
Member

I'm currently working on a project aiming to base VPython on wxPython, in part to be able to run on Mac Cocoa (and therefore on 64-bit Python on the Mac). It appears likely that the issue that concerns you will go away in this restructuring. In the meantime, you might consider doing your calculations on variables not associated with visible objects, and then quickly update the object attributes from your calculated values. It seems possible that this would make a difference.

@ShadSterling
Copy link
Author

Refactoring to separate calculations from updating visual objects made a bigger difference than I expected, more than tripling the maximum framerate. I doubt it prevents drawing incoherent states, but it does seem to have made it rare. Unfortunately, it still doesn't redraw at consistent intervals, even with a delay to ensure a consistent interval between rounds of updates to visual objects. The redraws sometimes seem to happen in pairs, as if some redraws are right after a round of updates and others are after some additional delay I don't control. Might it be an interference pattern with some hidden redraw rate visual uses internally? Updated code at http://pastebin.com/7aZpWqH9

I'm not familiar with wxWidgets, how would switching to that affect redraw timings?

@ShadSterling
Copy link
Author

After upgrading from Python 2.7 to 3.2 (from http://www.vpython.org/contents/download_mac.html ) the timing is much more consistent. I guess the delays were some sort of bug in 2.7? I'd still prefer explicit synchronization, but with the refactoring and the upgrade it's much more usable.

(Too bad the motivation for upgrading was attempting to diagnose #5 )
(Final version of my first attempt at using vPython at http://pastebin.com/VQXMUBNJ )

@BruceSherwood
Copy link
Member

I can't think of any reason why there would be any difference between Python 2.7 and 3.2 in this respect. Deeply puzzling. The connection so wxPython is very indirect. Suffice it to say that in the restructuring made necessary by having to be able to run on Cocoa a side effect is likely to be that scene updates will occur only on your demand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants