Closed mcourteaux closed 2 weeks ago
Closes #884
Fixed the capitalization in the screenshot: Inherit Colors
-> Inherit colors
.
Perhaps I should even change it to Inherit custom
?
Another example of this in my jobsystem. I used this to make every job get a different color:
Fixed the capitalization in the screenshot:
Inherit Colors
->Inherit colors
. Perhaps I should even change it toInherit custom
?
I would name it "Inherit parent colors".
I would also rename GetZoneParentsUntilTopLevel
to GetAllZoneParents
, with an assert that the final depth is the depth passed as an parameter.
One more thought: the zone timeline drawing routines are already passing through all the parents. Maybe it would be simpler to just pass the user zone color down to children right there, so that no parent lookup is needed at all?
One more thought: the zone timeline drawing routines are already passing through all the parents. Maybe it would be simpler to just pass the user zone color down to children right there, so that no parent lookup is needed at all?
I could do that, but that would require adding a uint32_t custom_color
field to struct TimelineDraw
, which you've been trying really hard to make it small it seems.
I would name it "Inherit parent colors".
I would also rename
GetZoneParentsUntilTopLevel
toGetAllZoneParents
, with an assert that the final depth is the depth passed as an parameter.
Will do.
I could do that, but that would require adding a
uint32_t custom_color
field tostruct TimelineDraw
, which you've been trying really hard to make it small it seems.
The amount of timeline items to draw turns out to be surprisingly low, so it's not a concern.
It's more annoying to implement than I expected. The utility function View::GetZoneColor()
is private
to View
. So from within TimelineItemThread::PreprocessZoneLevel()
, I can't use that function to get the color there and populate the TimelineDraw::customColor
field.
Just change it to public
.
Changed it and reverted old changes (rewrote git history).
This new approach also allowed me to implement correctly the color for the Folded zones:
Done 😄
I forgot that zone colors may come from two different sources, so I took a deep dive to understand the code and b359936c04e496c2c5a5a75d4aa5b0c4110aea4e is the result. Please take a look if everything there works as you'd expect.
You introduced a bug somehow, I believe. Neighboring zones adopt the color as well, randomly:
The zone pointed at does not have any color. Fix in #886 .
Option for coloring zones without custom color by inheriting it from a parent that has a custom color. If inherited, the color is made slightly darker to distinguish the "sources" of the colors and the ones inheriting from each other.
Option saved to ini file.
Performance considerations:
alloca()
'dScreenshot without:
With: