MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000005Scoring Application Prototype[All Projects] Generalpublic2014-05-14 00:352014-05-27 18:39
Reporterptrue 
Assigned Toptrue 
PrioritynormalSeverityfeatureReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionSprint #5Fixed in VersionSprint #5 
Summary0000005: Reduce amount of recalculation
Descriptionrecalculate() should be reduced in two directions:
1) only start from caret position (not from beginning)
2) only recalculate next system if current system bottom position or right-most vertical is changed and only recalculate next page if amount of systems on this page has changed.
TagsNo tags attached.
Attached Files

- Relationships
parent of 0000018resolved Introduce getMinimumHeight() and getPreferredHeight() for StaffSystemFragment 
parent of 0000020resolvedptrue Vertical scaling threshold for the ending pages 

-  Notes
(0000009)
ptrue (developer)
2014-05-19 02:46
edited on: 2014-05-20 14:35

Problem:
When page is being recalculated() we always recalculate one system of the next page in order to check if it can fit to the current page. So if it is decided not to continue to the next page then the first system of the next page will have wrong values.

Possible solutions:
1) Not to check that system. This is only possible if autoAlignment is turned off.
2) Check some precondition if it make a sense to check that system. Like if we have more material than previously then that system doesn't fit to this page for sure.
3) Save previous state of the system and then restore it if it stays on the next page.
4) Keep all the calculated values separate from the objects so that we just create a new "calculation object" and don't spoil anything by calculations.
5) Don't do the system fragment recaculation until needed. For checking use getMinimumHeight() and getPreferredHeight().


- Issue History
Date Modified Username Field Change
2014-05-14 00:35 ptrue New Issue
2014-05-14 00:35 ptrue Status new => assigned
2014-05-14 00:35 ptrue Assigned To => ptrue
2014-05-14 02:02 administrator Target Version => Sprint 0000004
2014-05-14 02:04 administrator Status assigned => new
2014-05-17 14:05 ptrue Status new => assigned
2014-05-19 02:46 ptrue Note Added: 0000009
2014-05-20 14:34 ptrue Relationship added parent of 0000018
2014-05-20 14:35 ptrue Note Edited: 0000009 View Revisions
2014-05-24 12:13 ptrue Target Version Sprint 0000004 => Sprint 0000005
2014-05-26 16:21 ptrue Status assigned => resolved
2014-05-26 16:21 ptrue Resolution open => fixed
2014-05-27 18:32 administrator Relationship added parent of 0000020
2014-05-27 18:39 administrator Fixed in Version => Sprint 0000005


Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker