Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000444TunixGeneral Featurespublic2011-11-28 12:042012-04-02 21:30
Assigned ToFred 
PlatformLinuxOSDebianOS VersionSid/Unstable
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24-SNAPSHOT 
Summary0000444: Colours Consistently Different In 2d View Of 3d Tables
DescriptionI'm sure you know about this, and I believe you mentioned it once, but we need this up here as a reminder at the very least. 2d views of 3d tables are coloured based on value, they come up by default looking reasonably, but change to another also reasonable set of colours once you run the cursor/keyboard through them.
TagsNo tags attached.
FirmwareVersionnot provided by submitter
Attached Files

- Relationships

-  Notes
dandruczyk (viewer)
2011-11-28 20:49

This is due to the 2D axis's being colored which shifts the scale.
User avatar (0000857)
Fred (administrator)
2011-12-02 19:06

I don't know if the latest fix was supposed to fix this or not, but if so, it didn't. The axis are indeed white, but the colours still change when you edit the cells. They don't change when you just move through the cells, though. Only on edit, and even if the value is visibly the same, and far too different to be accounted for by rounding. I hope this helps :-) Perhaps you can put the axis colours back in afterall?
dandruczyk (viewer)
2011-12-02 19:34

That is normal. Colors SHOULD change when the value does. The special case is a FLAT table, in that case the hi/low limits are the same, thus there isn't a smooth color transition. i.e. with benchtest firmware, the lambda table renders properly in both 2D and 3d with matching color sets.

The problem with the axis's having color is that to mtx it's considering its values AS WELL as the table's which skews the colors. (conversions make this even worse). removing the axis's from being colored syncs up the colors between 2d and 3d displays. (possible exception to all flat (not seen in real world use) tables).

The color span improves with the table span (As max table value to min table value range extends the color spread gets "better")
dandruczyk (viewer)
2011-12-02 19:34

AFAIK colors act properly, see previous note RE flat tables...
User avatar (0000871)
Fred (administrator)
2011-12-02 21:20

I don't understand why the axis values are considered in the colour span calculations, why not do it completely independently? Colour pallet limits? Not withstanding, though, it doesn't work correctly and seems basically unchanged. Lambda table being my test area. Deb Linux fwiw. I'm on f2fb286ea8e36c738d6e12266c6fff4d6febd050
dandruczyk (viewer)
2011-12-02 21:23

It's not for you to understand. (you refuse to look at code, so, that's the way it is.) The tables are not a nice single object, if they were, doing the colors the way you want would be possible), since they are just a huge pile of independent widgets, its unclean and a royal pain to do what you want, and hence not going to be done, and frankly I did try it at one point and it looked wrong in general.
Be more descriptive of what you see that's wrong. I compared 2d to 3d and the colors matched for me, so provide screen-shots or links to them.
User avatar (0000877)
Fred (administrator)
2011-12-02 21:32

That's the problem. I'm talking about the 3d tables, NOT the 3d view. I made sure to be explicit about that in the first place with "2d views of 3d tables". I've not opened the 3d view stuff in some time. This has all been more basic testing. The colours end up fucked up and inconsistent in the 2d view, of the 3d tables, 3d tables being tables with 3d data, which they are, two axis, and a value scale. If you need a screen shot and can't make it happen, let me know. All versions of MTX have always done this for me, and we've talked about it before, hence "I'm sure you know about this, and I believe you mentioned it once".
User avatar (0000878)
Fred (administrator)
2011-12-02 21:33

Also, this is self-contradictory: "its unclean and a royal pain to do what you want, and hence not going to be done, and frankly I did try it at one point and it looked wrong in general." :-)
dandruczyk (viewer)
2011-12-04 15:26

awaiting screenshots and a coherent description of what is wrong....
User avatar (0000892)
Fred (administrator)
2011-12-04 15:31 [^]

I did this simply by clicking into or navigating into each cell and hitting enter while in the cell.

I noticed something else this time, though, I clicked on the tab while things were still loading, and the other processes slowed this tab rendering down enough to see that the background was light blue and the orange got drawn over it from left to right.

I can't see a valid reason for two cells having different colours and the same visible values. I see that there is a bug, but the colour map should probably be based off of visible values not backing values, in order to give a consistent UI experience.
dandruczyk (viewer)
2011-12-04 21:41

Behavior should be improved in e1d012c24ad7c69375fc6396a0c6b2b8541788e3

Not 100% there yet, but better
dandruczyk (viewer)
2011-12-04 22:39

2d and 3d colors in sync now: dc176cc5832c68cfd095244b98480870765c885e
dandruczyk (viewer)
2011-12-05 03:00

100% complete on hash 77d6ca7b9b7706e825d2bb63fd35d0760ac13880

Table colors now properly behave and track 2d/3d. Expanding table limits will cause a full table color recalculation, with a delayed update, to avoid a gui slam, esp on shit/slow machines.
dandruczyk (viewer)
2011-12-05 03:00

test and close if satisfied....
User avatar (0000906)
Fred (administrator)
2011-12-05 13:30 [^]

3D view works a charm, but 2d fails to update until you hit enter in a cell.

I also still think that the colour range is ONLY OK in the 3d view and too violent and not progressive enough in the 2d view. Though I have an idea for that :-)
dandruczyk (viewer)
2011-12-05 13:33

That is CORRECT and NORMAL behavior.. values are NOT SENT until you hit enter to "Activate" the cell, or use the q/w/+/-/Pgup/Pgdn hotkeys as wiht those the "enter" is implicit..

Colors ARE synced between the two and match up, thus thuis issues is resolved as described.. So this tickets issue is resolved. open a NEW ticket if you want to discuss th
e color ranges.
dandruczyk (viewer)
2011-12-05 13:33

The issue raised in thjis ticket is resolved, iof you don't like hte color range, open a NEW ticket to discuss that.
User avatar (0000909)
Fred (administrator)
2011-12-05 13:37

No, it's not. Look again. Edit was done in 2d.
dandruczyk (viewer)
2011-12-05 13:50

Issues fixed in hash: 09af41c83234ac2b8fd30895403e00b7c9f1f415

In Freeems since the tables are 16 bit, only half the table was refreshing when color recalc was done. Fixed..
User avatar (0000911)
Fred (administrator)
2011-12-05 16:00

Yep, works nicely, and as a hack, you can set high boost low rpm cells to extreme values to give you a visual scale in 3d and set your colour profile to your taste. It would be nice if the app could allow you to do that without the hack, but it's very usable as-is and this bug is closed! :-)
User avatar (0001379)
Fred (administrator)
2012-04-02 14:53

This was "broken" again in a later commit (3ac521ae87b7e) in which it became an option on the general tab with a MS-centric default. This will require patching such that the default is correct for FreeEMS users. Adding info here because I found it difficult to find out how (it's not on the tables themselves).
dandruczyk (viewer)
2012-04-02 21:26

Broken in what way? Provide full NEW explicit details as to what you believe is "broken".
User avatar (0001383)
Fred (administrator)
2012-04-02 21:30

Not broken, "broken" :-p The default is "auto" which is unacceptable for FreeEMS users as a first experience. I might just distribute a patched version instead. If it needed to be reopened I would have... You keep getting confused about your roll on MTX issues. You fix and resolve, we open and close.

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker