Community
Participate
Working Groups
The Chart View seems to be broken. It appears gray when executing a simulation. Selecting a different chart type with the buttons above causes the chart to be repainted. This is a workaround to still see charts. This problem is not always reproducable. It seems to be a timing problem. When starting a simulation with the Chart View in background, I can always see the empty gray view.
Yep, I've been noticing that as well. The stuff that Urs did getting rid of the undisposed stuff was really needed but at the same time I think it might have upset a delicate balance somewhere. :) The BIRT stuff really wasn't designed for dynamic charting, and I remember having to spend a lot of time fine-tuning things to get it working reasonably well. In the meantime, I left all kinds of references floating in space. ;) But there were some things going on there that might not have been obvious. For example, the Ascape model is slightly different from standard MVC. Rather than: 1) Model updates 2) View Draws 3) View Reports Complete -> 1 It's 1) Model Updates 2) View get data it needs for update 3) view Reports Updated ->1 4) View actually does draw 2 blocks if 4 is still active so that you never have more than one view update queued up, but the idea is that views can work on the actual graphics after the model is allowed to continue. That can help with performance a lot. I don't know if that is in play here or not. In any case, charts have always been really slow. It's one of the reasons that the original Ascape implementation (using JFreeChart) is still much faster than the Eclipse version. If we could think of an easy way to replace BIRT I'd love to do it. For one thing it would get rid of a lot of build issues. :)
Urs just committed changes that remove some concurrency problems. The goal is to have only two Threads: one that simulates, one that updates the GUI (Main Thread). Trying to simplify this as much as possible to get rid of all concurrency problmes.
(In reply to comment #2) > Urs just committed changes that remove some concurrency problems. The goal is > to have only two Threads: one that simulates, one that updates the GUI (Main > Thread). > > Trying to simplify this as much as possible to get rid of all concurrency > problmes. OK, let's try to think about performance as well. Not that it is performing well now, but there shouldn't be any need to prevent the model from continuing once the chart get's the information it needs.
OK, again, this introduces a very serious regression. See bug 353372. I'm backing this change out into a separate SyncronousExperiment branch. Please make any changes there and do not introduce any synchronization or updating related changes into the main branch unless I have reviewed them. We will support the existing asynchronous approach unless or until we have another approach that is performant and that works for all cases.
