Community
Participate
Working Groups
Often when I run simulations, and this is on a Mac but I think other systems have similar problem, the Map view lags behind the simulation and frequently won't get updated for many iterations. Even setting the simulation pause between cycles to 1 second doesn't help. Updating the map is an asynchronous task and I think the system just gets overwhelmed. I'm wondering if it's really necessary to do this asynchronously. A quick test running it synchronously instead the system behaves much better and I can set the pause to 0 ms and still see smooth animations in the map. I didn't design this originally and there might have been a good reason for the asynchronous updates. Please add comments to this defect if anyone knows the reason. Otherwise I propose changing the updates to be synchronous instead. It's always possible to make the simulation run faster by closing the map view anyways.
The updates are asynchronous to remove the simulation computations from the Eclipse UI thread. That particular thread needs to be focused on processing UI events in order to maintain the responsiveness of the Eclipse UI. If the simulation computations were put on that thread the entire STEM interface would "freeze" when a simulation was run. Having the simulation pause for a second between cycles should provide a "chunk" of time for the display to be updated. What metric are you using to measure the "lag" of the Map view, cycles or time? Any idea how much lag there is?
We've pretty much solved being able to draw the STEM global geography (40,000 geographic nodes, 1.5 million tessellated polygons, ~8 million vertices) in hardware using OpenGL for the Globe project. It's very fast (panning/zooming, etc) and would allow for easy-to-implement map projections. Should be a relatively easy port over once the project is finished... biggest concern is you have to distribute the geographies in a pre-tessellated form which is quite large.
Dan, just a quick test on a square lattice scenario (50 x 50) and I often see the simulation running 10-15 cycles before I see any updates on the map (with 0 wait time). With 250 ms wait time it runs about 5 cycles before the map updates. I this scenario it seems able to keep up with the 1 second wait time, but I've seen other scenarios where it lags behind even then. The simulation computations are still run in a separate thread even if we use synchronous updates (since we're using Display.syncExec(...)), it's just that they would wait until the map is done redrawing before proceeding to the next cycle. If there's no map open the call would return right away. If we did it this way I don't think we would even need the user to specify the wait time between cycles. Matt, way cool. Do you know if you're using synchronous or asynchronous updates to the OpenGL map? But if it redraws that fast I suspect async would work just fine...
I understand a bit better now. I was thinking that you meant to co-mingle the simulation with the UI thread, which just won't work well. But, using Display.syncExec() instead of Display.asyncExec() make sense and is easy to try. I think there was only one call. I would expect that the display would stay responsive, but that the simulation would slow down because it now has to wait for the display to update for each computation/cycle. Some ideas: 1) add a menu option or preference to select either syncExec() or asyncExec() 2) parameterize the "sync'ing," by this I mean let the simulation run and do async updates of the display for a number of cycles, and then have it do one cycle of sync updates, repeat. As for Matt's openGl work, I thnk it's a no brainer to use that for STEM, can't wait to see it.
On the topic of syncExec vs. asyncExec in the current viewer... might want to validate it on a much larger graph (continent-level, China, Russia, etc) to see how sync vs. async behavior is. I know it takes 10-20 seconds to draw the map in SWT for the whole world and 2-3 seconds for some of the larger countries... I guess the question is whether we want to sacrifice simulation speed by waiting that long for a map to draw. A sync vs. async option might be nice. As for how the OpenGL version would work, OpenGL has an animation thread that runs at n frames per second (1<n<30 generally). We schedule updates at the end of a cycle into the animator, only redrawing geographic nodes that have a delta of 0.1 from what's currently drawn. On the next pass (or next few passes) of the OpenGL animation loop, it redraws the updated nodes.
Dan, I like you're idea of making it a preference. While it should be a simple as doing syncExec instead of asyncExce, the code in GeographicControl.refresh() is (just like the comment says) confusing. There's even a non-ui thread involved somehow. But I got it working yesterday mostly by changing thing to syncExec and then doing a join() on the job. Matt, from your description "we schedule updates and the end of a cycle..." I think it's an async call that would do the scheduling (the caller doesn't block for like 1/30th of a second)? Would it even be useful to be able to configure it to be either async or sync? Also, only redrawing polygons with a 10 % change is an excellent idea, we should have thought of that long time ago, it would speed up the current way we draw the map. What I'm trying to get out of this is whether it's useful to add the async/sync option right now, or if we should wait until we have the OpenGL map implemented.
Matt, Assigning this initially to you as I'm hoping the new openGL work will be our next viewer
Looks like this one dies in committee for now. JOGL (the key library here) is IP pending for > 2 years with no sign of resolution. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2840 We can reopen when (if) the library gets approved, but I don't see any point in spending time on it until then. Closing and marking as fixed to represent original change from asynchronous to synchronous updates.
