Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000626OLVUser Interfacepublic2012-07-23 19:362012-07-26 17:29
ReporterBenFenner 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.0.3-SNAPSHOT 
Target Version0.0.3Fixed in Version0.0.3 
Summary0000626: Frames Per Second display needs serious work.
DescriptionThe FPS display only works when the mouse-hover-info panel is getting updated. It also doesn't seem to be accurate. it also only updates once per second.

Make it better or more meaningful at least.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0001719)
BenFenner (developer)
2012-07-24 14:23

Git hash: 381d419e1e95b31fafe575c64bf807ddb4c2878c
User avatar (0001722)
Fred (administrator)
2012-07-24 14:55

Will close once the text is cleaned up: Ditch the square box, infinity and all negatives, please :-)
User avatar (0001723)
BenFenner (developer)
2012-07-24 16:03
edited on: 2012-07-24 16:35

Git hash: 97921cfff6be5d2b33e64fdc47c800a38c4d7b77

The following should no longer show up:
NaN
-0.0
-.0
*infinity symbol*

I'm not sure about the square box though. Hopefully it is gone too.

User avatar (0001724)
BenFenner (developer)
2012-07-24 19:40

Git hash: fba3eed61fb9f80248281c7e3094a436c498c72a

FPS display is accurate now (always) including when zooming. Had to hook into the paint method of the position bar since I couldn't for the life of my find a paint event to listen to.
User avatar (0001725)
BenFenner (developer)
2012-07-24 21:09

Fred is having issues where the FPS display outputs strange values when the program is "idle" and should be displaying 0.0 FPS. This is on Linux and Mac OSX. The painting that is used to determine FPS ceases on Windows, but continues at a slow rate on Linux/Mac so exactly 0.0 FPS might not happen on those platforms but Fred is getting huge numbers into the 2,000 FPS range.

More work is needed.
User avatar (0001726)
BenFenner (developer)
2012-07-24 21:47

Git hash: 1e48a50b1ed99f179170b6778b4d5476dc9019e6

It turns out that the reason for the issue above is that Linux/Mac cause a paint() once or twice a second which should result in an extremely low FPS read-out. However...

The issue is that if a single frame is "caught" in the sample window (250ms), it had no other frame to compare it to for time, so when ever it came in the window, it assumed that the rest would come in as quickly. So if it came in toward the end of the 250ms window it assumed about 4 FPS. If it came super early in the 250ms window it treated it like thousands of frames a second.

This should be fixed now.
User avatar (0001727)
Fred (administrator)
2012-07-24 22:23

It's not, and I'll have you know that I'm starting to feel guilty about your pain. Setup a VM at home. Beware of precanned linux images, they're usually full of adverts :-/ Install from scratch. Bonus will be being able to run EMStudio against fake freeems and see how it looks :-)
User avatar (0001729)
BenFenner (developer)
2012-07-26 15:13
edited on: 2012-07-26 16:19

Git hash: f19a77c502d073017f7ec6008d02398cfd8e18ad

After much going back and forth it looks like this is completed. And for whatever reason, I'm now seeing the same issues where idle produces painting, so while idle the FPS display shows some activity. These paint jobs are being triggered by the FPS display itself, which I will fix in a new issue.
New issue here: http://issues.freeems.org/view.php?id=629 [^]

Since the FPS display is triggering these paint events, the speed of the FPS display affects how many FPS it displays at idle. Interestingly enough.

User avatar (0001733)
BenFenner (developer)
2012-07-26 15:48

Moved this to target version 0.0.4 because it really facilitates performance testing. It didn't belong in 0.0.3 at least.
User avatar (0001738)
Fred (administrator)
2012-07-26 16:09

Moving back to 0.0.3 where it was, and where it is. :-/
User avatar (0001739)
BenFenner (developer)
2012-07-26 16:31

Moved this to target version 0.0.4 because it really facilitates performance testing. It never belonged in 0.0.3. That was my mistake.
User avatar (0001746)
Fred (administrator)
2012-07-26 17:27

Moving this to target 0.0.3 for the last, or second to last time, no more. Re read that sentence.

Professional issue tracker usage is as follows:

A) Issue is created by whom ever.
B) Issue is assigned a target version by a developer.
C1) Issue gets worked on once previous versions are released.
C2) OR issue gets moved to current release target group and THEN issue gets worked on.

Under NO circumstance is an issue worked on, on master/trunk, which is currently target for some later release. Issues in later releases that are prime for parallel work can be worked on on branches and rebased continuously until merged to master immediately after the previous release. For example, the XGATE BB stuff and the SD card stuff and so on will all be developed in parallel, then brought into the firmware proper once the preceding release is out.

What happened with this issue is that you:

* created it
* assigned it to 0.0.3 target
* worked on it with intent to complete it before 0.0.3 release, thereby having it in your mind as a target for 0.0.3 release
* regretted having started working on it, wanted to put it in 0.0.4
* carried on all the same, completed it before 0.0.3

While you were working on it your intent, target, if you will, was for it to be complete and functional on the master branch, from which OLV releases are made, the next of which being 0.0.3. It's not relevant that you wanted it to be in 0.0.4 nor that the description matches the arbitrary historic description of the 0.0.4 release. The only thing that is relevant is where it ends up, and why. The history of the issue clearly shows that you thought it should go in 0.0.4, and also that that didn't eventuate.

The tracker usage guide found here does not have version target, product, fixed in semantics in it. I will add that later today so that it's clear what's expected, and indeed required, of developers using this tracker.

http://forum.diyefi.org/viewtopic.php?f=41&t=1381 [^]

The point of the road map page is to show what is completed and going into a specific release. Because this change is on master, it's going into 0.0.3, and that is currently not shown on the roadmap page. Instead it's misleading showing that this fix goes into 0.0.4, which is untrue.

Target versions for issues are dynamic and agile and change over time with requirements and evolution. The final resting state of a target version is always the fixed in version.

Once again, the fact that it sits more cleanly in your head for this to be "in" 0.0.4 means nothing. It's not in 0.0.4 and at the time the work got done you did intend it to end up in 0.0.3, that was the target, like it or not.

Finally, before hitting edit again, read the first sentence in this comment, consider my wrist usage, and pull your head in.
User avatar (0001747)
Fred (administrator)
2012-07-26 17:29

Tested as fixed in f19a77c502d073017f7ec6008d02398cfd8e18ad


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker