Archived issue #0025698
Modeling Algorithms - Implementation of progress feedback in pave filler
Description
Progress indication is not implemented in BOPAlgo_PaveFiller. I created an implementation. See the attached patch.
Steps to reproduce
Not needed.
Public activity
9 archived notes
Participants are labeled by their role within this record.
Both patches needed.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Author
Date: Mon Jan 12 16:40:00 2015 +0100
0025698: Implementation of progress feedback in pave filler
[revision removed]
Detailed log of new commits:
Author: Author
Date: Mon Jan 12 16:40:00 2015 +0100
0025698: Implementation of progress feedback in pave filler
Dear pkv, please review the branch CR25698.
1. Replace the pieces of code
...
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->NewScope(100.0);
myProgressIndicator->SetStep(100.0 / 16.0);
}
,,,
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->Increment();
}
...
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->Increment();
myProgressIndicator->EndScope();
}
...
by methods that control the indicator. Say,
BOPAlgo_PaveFiller::IndicatorStart ()
BOPAlgo_PaveFiller::IndicatorIncrement ()
BOPAlgo_PaveFiller::IndicatorStop ().
Place the methods in a separate file [say BOPAlgo_PaveFiller_11.cxx]
The reasons:
- keep the one functionality in one place is easy to maintain and modify
- keep the control program out of details
2. Why the steps
myDS->UpdatePaveBlocks(); RefineFaceInfoOn();
are out of IndicatorIncrement ()
3. Why the all steps have equal complexity?
The complexity of a step depends on data.
It would be nice to have the analysis of data inside the code.
The analysis will allow to distribute the complexity of steps more correctly
4. It will be good to have a test command and several test cases
to see how it works. These tools are absolutely necessary to identify
the problems associated with Progress Indicator in context of
BOPAlgo_PaveFiller:
- The Draw command is needed.
- Steps To Reproduce is needed.
- Test cases are needed.
...
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->NewScope(100.0);
myProgressIndicator->SetStep(100.0 / 16.0);
}
,,,
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->Increment();
}
...
if (!myProgressIndicator.IsNull()) {
myProgressIndicator->Increment();
myProgressIndicator->EndScope();
}
...
by methods that control the indicator. Say,
BOPAlgo_PaveFiller::IndicatorStart ()
BOPAlgo_PaveFiller::IndicatorIncrement ()
BOPAlgo_PaveFiller::IndicatorStop ().
Place the methods in a separate file [say BOPAlgo_PaveFiller_11.cxx]
The reasons:
- keep the one functionality in one place is easy to maintain and modify
- keep the control program out of details
2. Why the steps
myDS->UpdatePaveBlocks(); RefineFaceInfoOn();
are out of IndicatorIncrement ()
3. Why the all steps have equal complexity?
The complexity of a step depends on data.
It would be nice to have the analysis of data inside the code.
The analysis will allow to distribute the complexity of steps more correctly
4. It will be good to have a test command and several test cases
to see how it works. These tools are absolutely necessary to identify
the problems associated with Progress Indicator in context of
BOPAlgo_PaveFiller:
- The Draw command is needed.
- Steps To Reproduce is needed.
- Test cases are needed.
Dear pkv, I see that this task is not so simple as seemed. So, please, put it in your list of tasks.
The issue shall be reconsidered following integration of #0025748
This issue will be fixed with "21264 - Progress indicator for Boolean operations".
Please close this bug as duplicate of #21264.
Branch [archived branch] has been deleted by Commenter 3.
[revision removed]
[revision removed]
Related records