With the new automatic handle algorithm, it is possible to do a lot
of the animation via keyframes without touching the curves. It is
however necessary to change the keyframe interpolation and handle
types in certain cases. Currently the dopesheet/action editor
allows changing the types, but does not show them in any way.

In addition, it is sometimes helpful to know the general direction of
change of the curve, and which keys are extremes. This commit also adds
highlighting of extremes, based purely on comparing the keyed values
with adjacent keys (not taking overshoots between keys into account).

This was previously discussed a bit a year ago here on Blender Artists.

The main thing is that as said in the description, the editor allows changing interpolation on a keyframe, but no way to see the result, even for the most common modes. The extrema are just a bonus to be able to see where the key sequence changes direction; maybe them being somewhat hard to see (or in other words, not being in your face) is actually good.

The premise and goal of this is clearly useful. No doubt about that. However, I'm not sure the actual design choice here is the best we could go with.

The biggest issues I see are:

The symbols used seem random. It's not possible to actually work out what they represent. They are too cryptic.

These symbols don't show the actual falloff, or in which direction the curve falls. Does it ease in or out? Does the effect go forwards till the next key or backwards? Not clear.

So, an alternative solution to the same problem would be to try and convey this information in a different way. Because we are communicating the falloff between keyframes, I think we should try and actually convey it there - between the keys.

Here are three alternative solutions presented:

The advantage of this approach is that we communicate what is actually happening in a way you can actually see, rather than using cryptic icons that you have to learn and remember, and which don't communicate easing, falloff or directions.

It's also more consistent. Currently we communicate held keys this way, with a solid bar between two keyframes, so you know it's a hold.

The Gradients seem more useful for color values (or something changing from 0 to 1)

The Graphs (Curves) seem more useful for movement and scale and rotation.

It always confused me personally to discern between common values (animated materials or environments) and location/rotation/scale values.

Although I don't want to propose that these 2 should use different visual representation because of this. It might also be better to just color code them differently - simple values can have grey (as in node editor = shader editor) - color values can have yellow (as in node editor = shader editor) - rotation/location/scale can have the colors of keyed axes together or dashed in alternating colors..

Would have to use such a system to really judge if it's good to use different ways of representation for each "type" of keyframed value.

The icons seem least useful to me because I am very visual and the icons don't connect those 2 keyframes together but I can see myself switching to it when a more general overview (when zoomed out for example) is needed.

Looking it again today, I still have serious doubts about the legibility of these markings. They are almost impossible to distinguish and it's also hard to understand what exactly each symbol is trying to convey.

Maybe we can consider again trying different keyframe shapes (in addition to the diamond) again. However, IMO whatever shapes are chosen must make it clear what point in time the keyframe exactly sits. Currently the keyframe diamonds do this by having the north and south points at the middle of the top/bottom of the icon's bounding box. For other shapes, the simplest solution is to include a vertical line going through the middle of the shape/bounding box (I'd suggest also that this line should ideally extend outside the box, so the silhouette is affected, instead of being another thing inside the shape).

Don't pass SpaceAction to all of these places:

a) It's overkill for getting access to a single setting,

b) Some of the draw key functions are executed from other places too

What's going on with all this BezTripleChain stuff?

a) What's it supposed to achieve and why?

b) On the code side, something doesn't feel quite right with this (aka there are probably bugs/hidden gotchas here)

@William Reynish (billrey) Nice idea. Personally, numbers 1 & 2 are the more promising ones there - on an aesthetic level, I like 1 more, but 2 probably communicates what's going on better (as the gradients make subtle differences harder to see). The only potential issue here is regarding performance, but as long as we don't care too much about accurately representing the transition between the keyframes (i.e. no sampling of the curves to find out what's going on, and just using some prebaked effects in fragment shaders) I think we can do it (in which case, 1 is actually more convenient to implement).

These symbols don't show the actual falloff, or in which direction the curve falls. Does it ease in or out? Does the effect go forwards till the next key or backwards? Not clear.

That is because communicating 'falloff' is totally not what is the point of all this. The goal is to be able to animate with interpolation (i.e. not keying every frame), but without using the curve editor for most of the job. I.e. keyframing visually in the 3D view, and moving/changing important key types in the Dope Sheet.

I chose the 7 icons I implemented specifically because of their basic algorithmic importance for interpolation.

First there are bezier handle types:

Auto Clamp is the default keyframe type. Blender will automatically trace a smooth curve through the keyframed values, but will not overshoot extremes. Since it's the default, the icon is the raw diamond.

Auto also specifies a smooth curve, and also allows overshooting extremes. Since it's similar to Auto Clamp, the icon just adds a small dot. You would use this type if you prioritize a smooth motion above precise control.

Vector is also an automatic type, but it specifies a sharp change in the curve direction. This is a key type to use when an abrupt change in motion happens. The icon is basically 'v' in the diamond, or a bounce.

"Other Bezier" handle types: they are all not automatic. This means you can't deal with them without the Curve Editor, so there is no point distinguishing them in the Dope Sheet. The icon is 'X' for danger, as naively retiming such keys from the Dope Sheet will distort the curve.

These are definitely properties of the keys themselves, not something that happens between them. You actually have two handles per key too, but fortunately the automatic types must be paired.

Then there are interpolation types. These actually do belong in the middle between two keys, but I just made them icons to avoid implementing separate systems:

Linear specifically defines simple linear interpolation between two points. This actually can also be done with Vector handles on bezier curves.

Constant keeps the value constant, until the next key, where it abruptly changes.

Other interpolation types. I don't really find them that useful because of how rigid they are, and you need properties like easing direction to fully use them, so you need the Graph Editor anyway.

So, a big complication is that in reality we have two settings here: interpolation and bezier handle type.

Interpolation sets a mode for computing the curve for a segment between two keys. It would be appropriate to communicate it somehow in between the keys, but it would require adding something completely new, and the thing is I don't really care about most of the modes.

Bezier handles are the properties of the key itself (although only meaningful within segments in bezier interpolation mode), and the choices that I actually want to communicate are all automatic, i.e. inheretly algorithmical and abstract and not some canned 'falloff'.

Alexander Gavrilov: I understand what this does. You want to visualize the Keyframe Interpolation inside the Dopesheet to lessen the reliance on the Graph Editor. Again, I think that's a good idea, but these icons are too cryptic and don't actually communicate very much.

Keyframe interpolation does happen between two keys. It affects the curve between the current key and the next one. But those little icons don't reflect that - it looks like it changes the keyframe value itself somehow, which it doesn't. So, I think we should make it clearer what is going on.

A few more examples of various interpolations and easing visualized in the Dopesheet:

What's going on with all this BezTripleChain stuff? a) What's it supposed to achieve and why?

This is for marking extremes, i.e. key values that are greater or less than both their neigbors. You need to know these neighbors to do that, so just one key is not enough, and for cyclic curves they won't even be continuous in the array at the ends. You can see the extreme marks in the screenshot as thin back lines at the top and/or bottom of the key.

The point of this is to see keys where the curve changes direction, and which thus are more important because they define the range of motion.

I believe however that when it comes to math functions the Graphs (Curves) are more reliable when being read. I can see that here differentiating between bounce and quadratic is easy but what about differentiating between Linear and Quadratic? When it comes to telling all the falloffs apart the Curves is the clear winner.

On the other hand though, Gradients are better for RGB values where the value's intensity and/or color is important (or maybe when the value is color = changing from blue to red to orange as can happen when RGB values are keyframed.

Keyframe interpolation does happen between two keys. It affects the curve between the current key and the next one. But those little icons don't reflect that - it looks like it changes the keyframe value itself somehow, which it doesn't. So, I think we should make it clearer what is going on.

I don't really care about interpolation, I care primarily about handle types. And those actually translate into equations in a system used to solve for a good bezier curve that passes through all specified key points.

Edit: it may be good to somehow distinguish between interpolation in general, and interpolation mode in blender. I do care about interpolation in general, but find most of those interpolation modes too rigid/mechanical to be useful outside of very specific use cases. Bezier is what everybody uses in 99% cases, and handle type is its main parameter.

It may be important to know that I had this idea and initially implemented it while thoroughly testing D2884, which implements a much better algorithm for automatically creating a curve from keyframes, making it possible to avoid manually cleaning curves up in the Graph Editor. You do need to be able to change between the automatic handle types to match the situation though, and Dope Sheet can do that, but you have to be able to see them; hence the icons.

All the non-auto-handle icons are simply there so you can see that something non-automatic or otherwise complicated is going on and you should probably look in the Graph Editor.

@Adam Preisler (Alphisto): Yes, the curves are clearer overall, I agree, and also more clearly communicate the connection to F-Curves.

@Alexander Gavrilov (angavrilov): Hmm, in that case I'm a bit confused. You mention Linear/Constant/Bezier. These are interpolation modes, just like Easing In/Out (via various strengths) and the Dynamic Effect Interpolations. All of these things are keyframe interpolation settings between two keys. This would be possible to visualize in a helpful way, and it's useful because the result is predictable and understandable.

The free/aligned/auto-clamp settings on the other hand are handle settings that change the angle of the keyframe handles. To me this seems less useful, because it's not predictable. The difference between Free and Aligned handle types depends on how you've then angled those free handles, and so IMO it's not really useful to even try and communicate that in the Dopesheet - you need the Graph Editor anyway to edit this.

The free/aligned/auto-clamp settings on the other hand are handle settings that change the angle of the keyframe handles. To me this seems less useful, because it's not predictable. The difference between Free and Aligned handle types depends on how you've then angled those free handles, and so IMO it's not really useful to even try and communicate that in the Dopesheet - you need the Graph Editor anyway to edit this.

Free and Aligned are all non-automatic handles and thus I represent them with one <X> "here be dragons" icon. The important ones are the automatic Auto, Auto Clamp and Vector handles, which do not have any other user-specifiable parameters - the handles themselves are computed by blender automatically based on this mode choice by the user, and the values of the keys.

Animators don't really want 'predictable' rigid modes, they ideally want to key some poses in the 3D view and have blender magically trace the right curve through it. Blender tries, but since it's not magic, this automatic mode has a few choices re how it can deal with a key - currently those 3 of them.

Free and Aligned are all non-automatic handles and thus I represent them with one <X> "here be dragons" icon.

I had no idea that those were dragons! The smaller blue one looks like 3D cursor from 3D view and the bigger one looks like classic Move / Pan icon in many softwares. Tbh I find it confusing although it definitely holds more data and it would be good to have it in Dope Sheet just maybe styled differently.

If you try to deal with them without using the Graph Editor, they certainly are. For instance, if you scale an auto-keyed stretch of animation in time via Dope Sheet (or move keys in time), auto handles will adapt, but manual ones won't and your curve won't be smooth anymore.

If we can visualize the difference between aligned/free/auto-clamped handles in a clear way I'm not necessarily against it, but note that we don't even use icons for these settings - they are rather abstract.

If we were to try, I think we should go in a more communicative direction by trying to visualize what the handles then look like.

If we can visualize the difference between aligned/free/auto-clamped handles in a clear way I'm not necessarily against it, but note that we don't even use icons for these settings - they are rather abstract.

Well, they really are abstract, so I don't see what's too abstract about my diamond icons for those; especially if you specify not increasing the size of the icon in any way as a prerequisite - you don't want to compromise the information density of the dopesheet because of some 'looks nicer' reasoning.

P.S. FYI just in case you are curious: Auto really means 'continuous second derivative'; Auto Clamp means 'ditto, unless a handle would overshoot an adjacent key'; Vector means 'zero second derivative on either side without first derivative continuity'; Free and Aligned are both completely manually specified border conditions for the equation system.

For instance, if you scale an auto-keyed stretch of animation in time via Dope Sheet (or move keys in time), auto handles will adapt, but manual ones won't and your curve won't be smooth anymore.

@Joshua Leung (aligorith) Not sure as I hadn't animated a lot recently but this could be a possible annoyance for people using the dope sheet as it very easily happens without user's knowledge unless you know and even then it can be gruesome to locate keyframes that can safely be adjusted as discussed here..

Don't pass SpaceAction to all of these places: a) It's overkill for getting access to a single setting, b) Some of the draw key functions are executed from other places too

Changed to pass around the flags instead.

What's going on with all this BezTripleChain stuff? a) What's it supposed to achieve and why? b) On the code side, something doesn't feel quite right with this (aka there are probably bugs/hidden gotchas here)

As said above, this is for passing the neigbors together with the key so that extremes can be computed. The only other way is to store the extreme status into BezTriple somewhere, which is bad because it's storing temporary runtime data into a DNA struct.

After more testing I decide the extreme lines look bad, so I tried to make the top or bottom outline thicker instead.

I'm also starting to really hate this newfangled dark color map, especially in DopeSheet. The old map has neutral gray background which has good contrast with both bright and dark elements, and gentle colors, while this new map dropped the background brightness way down without changing the brightness of any other elements, so contrast is all over the place, and colors on the left are garish. I never understood all this dark background fashion in any case, and actually find it more difficult to read very bright symbols on very dark background.

One thing is that a very small set of even completely arbitrary icons may be easy to learn gradually and naturally, as they appear in direct response to changing the handle and interpolation types. The intended use for this display feature isn't just turning it on suddenly on a complete animation and thinking 'what is the meaning of all this stuff', it is to be used during the whole process of making an animation from scratch, especially in the early to middle phases. This would naturally introduce the icons one by one.

In this view, the icons being easy to distinguish between each other at a glance, but not too visually noisy, may be overall higher priority than considerations of them being 'intuitive' for someone who has never seen them before.

I also wonder if the extreme display should be a separate option or not.

@Samir Osman (Samirosman): That's looking promising. However, as per my previous comments, it's unclear with some of these what frame exactly those things sit on. The arrow like ones are particularly bad in this regard, but to a lesser extent the square (constant) and circle are also not great.

Again, interpolation doesn't matter, it is only very rarely useful, except for constant and maybe linear (although it's redundant to vector bezier handles). The main thing is bezier handle types.

Also, consider that these different icon shapes are completely arbitrary (especially the simple square/circle etc) and go fully against any 'intuitive' argument. And note that icon size and color varies (the keyframe type option), so bitmap icons can't be used.

In the interest of reducing visual noise, I thought it may better to actually reduce line width:

Samir: This has promise for the key types - Vector/Aligned/Auto-Clamped - all the things in the V-key menu. This general direction is more readable and much clearer and communicative.

But for the interpolation modes (Linear, Easing in/out, Constant, Back, Bounce Elastic etc - everything in the T-key menu) I don't think it works. You can't see in which direction the interpolation goes (does it apply to the next keyframe interval or the one before the key?) Those should be visualised between the keys I think, in order to be clear about what they actually do.

The interpolation is something that changes how a curve goes from A to B positions, so it should be visualized as such.

I'm confused - many of your indicators *are* for interpolation types. It seems like you are mixing the display of some keyframe handle options (V-key) and some interpolation modes (T-key). I think the distinction should be clear between them.

Interpolation modes I think are very useful, and exactly the main reason why we can lessen the reliance on the Graph Editor. If we could visualise the interpolation between the keyframes inside the Dopesheet in a clear way, it would be very useful.

Regarding usefulness of interpolation, do you have any experience animating?

From watching guides and doing tutorials, I understand that real animators advise focusing on how things look in 3D View, i.e. setting good poses, watching the motion, and using tools like motion paths to check spacing etc. This process results in setting key values, which are then automatically interpolated via bezier splines.

Then if the interpolated motion isn't ideal, you could do either of two things. If you are a pro and work on movie quality stuff like Hjalti, you would actually manually interpolate yourself, adding more in-between keys. If you are in a hurry, or a beginner, you would instead go into the Graph Editor and tweak the curves by using manual Aligned/Free handles; before D2884 tweaking was mandatory because curves always had unnecessary kinks. In any case, you would still use Bezier interpolation; although if you manually interpolate down to the one key per frame level, you might as well use constant.

The major use for the Constant interpolation mode is blockout (initial setting of major poses), where you don't want to be distracted by the automatic bezier interpolation, which is unavoidably poor at this stage due to lack of data. Linear might be useful as a quick alternative to setting all handles to Vector, especially if you want to do it temporarily and then restore original handles.

Other 'interpolation' modes are really a gimmick, that results in very mechanical motion, which isn't really useful even for advanced bouncing balls, because to get interesting motion it usually has to be exaggerated from mathematically pure curves. I only imagine them being useful if actually animating a mechanism or a realistic natural phenomenon.

If you consider this workflow, the only things you need to see in DopeSheet is bezier handle types (Free & Aligned can be conflated), and Constant/Linear/Bezier/Other interpolation modes. The rest is either rarely useful, or requires Graph Editor anyway. The interpolation modes btw are set on the key starting the interval where it is active.

Samir: This has promise for the key types - Vector/Aligned/Auto-Clamped - all the things in the V-key menu. This general direction is more readable and much clearer and communicative.

But for the interpolation modes (Linear, Easing in/out, Constant, Back, Bounce Elastic etc - everything in the T-key menu) I don't think it works. You can't see in which direction the interpolation goes (does it apply to the next keyframe interval or the one before the key?) Those should be visualised between the keys I think, in order to be clear about what they actually do.

The interpolation is something that changes how a curve goes from A to B positions, so it should be visualized as such.

I agree that they don't work for the T-key interpolation modes but they do work for the V-key modes.
The T-Key modes could work nicely with your proposal but I think it should be an optional overlay.
The icons I chose are kind of based n my previous experience with keyframe icons in other packages.

@Samir Osman (Samirosman): That's looking promising. However, as per my previous comments, it's unclear with some of these what frame exactly those things sit on. The arrow like ones are particularly bad in this regard, but to a lesser extent the square (constant) and circle are also not great.

Thanks @Joshua Leung (aligorith) here is a quick update adding vertical lines to align with the timeline grid that might help clarify on which frame the icon sits.

@Alexander Gavrilov (angavrilov): Yes, I have done lots of serious animation. I did most of the animation on Big Buck Bunny years ago, a sizeable part of Sintel and more recently short films Whole, and a new film called Home Grown. Anyway, this is not a pissing contest or about that :)

The point is, how can we make the Dopesheet clearly communicate information to the user, to lessen the reliance on the Graph Editor. This is useful for character animation, but perhaps even more for motion graphics, which often make use of all the other interpolation modes too. That is our goal here.

Here's what I think we should do:

We add a menu in the Dopesheet under the View menu called 'Keyframe Display'. This has a few options:

1: Show Interpolation (on/off)

With this option on, we can show the transitions from A to B according to the Interpolation mode chosen by the user, like so:

2: Show Min/Max keyframes

This option, which you've already coded, makes it so that we display whenever a very is higher or lower that its two neighbours. However, the indicators for this needs to be clearer, like so:

3: Show Handle Types
This option displays the handle types of each key. Could look something like this, which communicates what the handles are doing:

With this approach, the indicators present intuitive and communicative information to the user, so that they can look at the Dopesheet and work out what is going on, without having to use the Graph Editor. If we make the information too confusing or too cryptic, users will have to have the Graph Editor open to see what's going on, which defeats the entire purpose of these features.

@William Reynish (billrey): Looks good. By and large, what you've got there makes sense - I particularly agree that we do want these different draw styles to be able to be turned on/off as needed; indeed it's something that some of the earlier mockups really drove home.

The only thing that's a little unclear is how the min/max and handle type options interact. I'm guessing though that the min/max style would take precedence in that case?

@Alexander Gavrilov (angavrilov): Yes, I have done lots of serious animation. I did most of the animation on Big Buck Bunny years ago, a sizeable part of Sintel and more recently short films Whole, and a new film called Home Grown. Anyway, this is not a pissing contest or about that :)

Basically, I was trying to say that I mean this for character animation :)

The point is, how can we make the Dopesheet clearly communicate information to the user, to lessen the reliance on the Graph Editor. This is useful for character animation, but perhaps even more for motion graphics, which often make use of all the other interpolation modes too. That is our goal here.

The thing is, the space in Dopesheet is limited, so the more information you try to communicate, the more difficult it becomes. I'm afraid that all those different types of interpolation modes may be too much. I agree that the interpolation belongs between keyframes though.

We add a menu in the Dopesheet under the View menu called 'Keyframe Display'. This has a few options:

Three options is too much. Interpolation and handles are the same conceptual thing, they just are implemented weirdly. Plus, if interpolation is placed between keys, they don't even conflict.

3: Show Handle Types
This option displays the handle types of each key. Could look something like this, which communicates what the handles are doing:

The problem is that those icons don't work as replacement for the key diamons for reason of size, complex shape etc.

I think it's futile to be able to display both the handle type and the min/max display. I can't think of a clear way to combine these things. I think it was to be an enum, so you show nothing, Min/Max or the handle type.

The interpolation display is then a separate thing from that and can be enabled independently.

As for character animation vs motion graphics: Displaying the interpolation is useful for both. Character animators use Constant & Linear very often. Motion Graphics folks use Easing In/Out and the Dynamic Effect interpolations a lot. This is not only useful for character animation - in fact it's potentially even more useful for motion graphics where the final animation might be comprised only of easing interpolation.

@William Reynish (billreynish) I had a go at it and figured something out.. but question remains how it works in the dope sheet UI and also how it feels during work..
I noticed that different handle types use different colors for their handles in 2.79b at least. That is not too bad, but the problem is that for example aligned and auto-clamped use almost the same shade of pink. So maybe long dashed and dotted could be introduce to ease this up a bit.

The obvious big issue is if colors should be used if Axis information is introduced in dope sheet..... So that those diamonds start getting red green blue or be tricolored according to the axis they operate on. Then suddenly all this extensive coloring goes to trashbin.

Personally I wouldn't mind the Colored option... Colorfull seems too much but possible is most visible from far away.

I found out though that while combinding these two types of information (normal min max and handle type) it's of utmost importance to not put anything "over" the diamond. So those were basically my rules here..

Also attached is the inkscape file in case someone wants to give it a go and alter some stuff..

@Adam Preisler (Alphisto): Yikes, I don't think that will work in practice. That's way too information dense and will just look like visual noise. You have to understand that these icons will be displayed really small and there will be loads of them.

To be useful, this feature has to be simple and clear to the user, otherwise it's just visual noise and random shapes.

@Adam Preisler (Alphisto): Yikes, I don't think that will work in practice. That's way too information dense and will just look like visual noise. You have to understand that these icons will be displayed really small and there will be loads of them.

To be useful, this feature has to be simple and clear to the user, otherwise it's just visual noise and random shapes.

Yeah I agree that zoomed out this gets cluttered fast.

However I would like the Normal Min Max be like this, so that the shape is always the same and also, max is at the top and min is at the bottom.

Maybe we can consider again trying different keyframe shapes (in addition to the diamond) again. However, IMO whatever shapes are chosen **must make it clear what point in time the keyframe exactly sits**. Currently the keyframe diamonds do this by having the north and south points at the middle of the top/bottom of the icon's bounding box. For **other shapes, the simplest solution is to include a vertical line going through the middle of the shape/bounding box** (I'd suggest also that this line should ideally extend outside the box, so the silhouette is affected, instead of being another thing inside the shape).

Why are you so focused on wanting such extremely precise midpoint? Normally keys are placed at integer frames, so as long as there is a midpoint (the symbol is horizontally symmetrical), I actually don't see a problem if it's a circle or a square. In fact, if we move interpolation display to be between keyframes, something as simple as this could work:

Auto ones are a circle because they are "smooth"; and they are so very similar (and the explanation of the difference so abstract), that just a dot is enough in my opinion - and I can't come up with any other simple shape. Auto Clamp is the default, so it's the one without the dot.

Vector results in straight lines or corners, but is still automatic, so it's a square.

Aligned and Free are manual and have to be treated with care in Dopesheet, so it's the more spiky looking diamond. I don't care if they are the same icon, but you could add a dot to make all 5 options different.

Can the icons be scaled up and have more white space between keys? Asking more as a UI question if icons can scale together with text tbh (are vector). Or are the icons bitmap? Good job this looks great now just the interpolation with the curves, that would be a massive help with motion graphics.

The icons are actually drawn by code (the glsl shader to be precise), so they can be any size.

The complexity of drawing interpolation obviously depends on how exactly you want to draw it, but will likely require making a new shader. Currently those lines are in the same 'flat color rectangle' draw call as holds.

From all the proposals I can easily see this becoming visually information overload.

Just like with viewport visuals, some projects/workflows require a lot of information and some require just a little bit of specific information. Being able to toggle on/off some of this stuff will be crucial.

@Hjalti Hjálmarsson (hjalti): it’s my clear impression that these features are options that one will be able to enable or disable. As you say, this extra information may or may not be useful depending on what you are doing.

In general though, a more communicative Dopesheet is very useful I think, for many types of animation. For example, the way we currently communicate that something is a hold, is already very helpful. This just takes things to the next level.

I agree that, if all these things are enabled at the same time, it could be information overload. I think it’s important that you can see only interpolation or the handle types or the extremes alone. In fact I think it’ll be most useful when enabled separately, rather than everything at once.

Looks good to me. Again, I think the combined display with both the extremes *and* handle types is too confusing and information dense, but I suppose it's nice that it works if you really do want to combine the two display options.

As for review, I would accept it from a UI and usefulness perspective, provided that you can toggle these independently. Someone else will have to do the code review though.