z-ordering issue when using drawModulationDragger/drawModulationDragBackground

Orvillain

When drawing a custom box using drawModulationDragger and drawModulationDragBackground, there is a z-ordering issue with other controls.

Any components that occupy that same screen region will paint on top of the modulation dragger output.

@Christoph-Hart is this a known issue???

Orvillain

Is there anything I can do about this??

Am I going to have to write a custom script panel that targets all of the mod depths via the mod matrix API ???

Christoph Hart

@Orvillain I think that was a custom request from @DanH - he was complaining that the mod draggers mask sibling components so I added some code that give them the same z-level as the knob that spawns it.

Check:

https://github.com/christophhart/HISE/blob/2b3d9bc0b3cb5817dcda1f5bd6366aba123531ab/hi_core/hi_core/MacroControlledComponents.cpp#L1280

If you remove the pIndex+1 parameter, the component is added at the bottom of the list with the highest z-order. Does that fix your problem? Let me know if it does, then I'll check where I can add this property so you can control it dynamically (and ideally per component).

Orvillain

@Christoph-Hart said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I think that was a custom request from @DanH - he was complaining that the mod draggers mask sibling components so I added some code that give them the same z-level as the knob that spawns it.

Check:

https://github.com/christophhart/HISE/blob/2b3d9bc0b3cb5817dcda1f5bd6366aba123531ab/hi_core/hi_core/MacroControlledComponents.cpp#L1280

If you remove the pIndex+1 parameter, the component is added at the bottom of the list with the highest z-order. Does that fix your problem? Let me know if it does, then I'll check where I can add this property so you can control it dynamically (and ideally per component).

haha, I literally just went digging through the code and found that line. Testing that fix locally. Will report back.

Orvillain

@Christoph-Hart Yes, that fixes it.

I did this:

pp->addAndMakeVisible(this, -1);

But I'm guessing the -1 isn't even necessary.

I'm honestly struggling to think of a scenario where you wouldn't want these depth knobs to always be on top of everything, to be honest!! But... if there is a need to support dynamic z-order assignments, then I'm a +1 to that!

DanH

@Orvillain I found the scenario!!

Orvillain

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I found the scenario!!

I'm curious what it was ?

DanH

@Orvillain any panel that you want to appear at any point, let's say a floating mini preset menu, or a floating tooltip, or a page, the draggers will sit on top of. However mine are persistant, rather than appearing on hover, so that changed the dynamic a lot.

Orvillain

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain any panel that you want to appear at any point, let's say a floating mini preset menu, or a floating tooltip, or a page, the draggers will sit on top of. However mine are persistant, rather than appearing on hover, so that changed the dynamic a lot.

I don't get it. Why are those things related to drawModulationDragger/drawModulationDragBackground ??

DanH

@Orvillain because my draggers (depth knobs) are always visible. All of them. So if I switch panels then the draggers still sit on top of the new panel. Make sense?

Orvillain

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain because my draggers (depth knobs) are always visible. All of them. So if I switch panels then the draggers still sit on top of the new panel. Make sense?

Yeah that makes sense. I think I might’ve been tempted to handle it a bit more locally rather than adjust the framework, it seems a bit sledgehammery to me, because I think the majority expected behaviour is that these mod depth knobs always sit on top of everything, and disappear when you move the mouse away. But that’s just my instinct. Interested to hear your thinking.

DanH

@Orvillain There should probably be an option for either. There's also the labels to think about as well... It's not a one size fits all solution.

Orvillain

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain There should probably be an option for either. There's also the labels to think about as well... It's not a one size fits all solution.

I just found another issue too - when you have your knobs inside a panel, that panel can easily clip off the floating popup for these depth knobs.... which is kind of annoying. Maybe the best solution for me actually IS to write a custom script panel that knows what knob we are hoving over, and assigns the depth knobs dynamically.

Orvillain

@Christoph-Hart

		// Walk up to the top-level component to avoid clipping by
		// intermediate parent containers (e.g. panel areas).
		if(auto pp = parent->getParentComponent())
		{
			// Convert drag areas and label from parent-relative to top-level-relative coords
			auto topLevel = parent->getTopLevelComponent();
			auto parentOriginInTop = pp->getLocalPoint(topLevel, juce::Point<int>(0, 0)) * -1;

			dragAreas.offsetAll(parentOriginInTop.x, parentOriginInTop.y);
			
			if(!labelArea.isEmpty())
				labelArea.translate(parentOriginInTop.x, parentOriginInTop.y);

			topLevel->addAndMakeVisible(this, -1);
		}

For my usage, I had to change to the code above.

I think we need the Z-order to be dynamic. But I also think the parenting strategy needs to be dynamic. Either DirectParent, or TopLevel. How easy would that be to add?

DirectParent == current behaviour, where you want a container panel to clip the hover panel.
TopLevel == popup always floats about everything; probably correct for 99% of use cases.

DanH

@Orvillain Have you tested with zoom factor? Had issues with this...

Orvillain

@DanH Not yet actually! Potentially another good reason to just build a custom panel.

Christoph Hart

@Orvillain yup, reasonable request. I'll add a field to the obj that you create with getModulatorDragData() (or whatever it's called), then you just add

obj.alwaysOnTop = true

and it will use the main interface as parent. Rescaling should work without issues.

Orvillain

@Christoph-Hart Lovely stuff! Thanks!

Christoph Hart

@Orvillain alright, I've fixed it. I also added the default positions to the dragAreas list so that the minimal roundtrip for the getModulatorDragData function works.

Note that if you're manually populating the dragAreas field with your custom position (as eg. the MatrixModulator tutorial snippet does), your custom positions will still prevail - it detects a mismatch between the number of sources to display and the given areas and picks the ones at the end of the list (since they will most likely the ones you tucked onto the already populated list).

The minimal example that shows the functionality is this. flip alwaysOnTop to true, then it will not be truncated by the parent (or hidden by sibling components). default is false for backwards compatibility.

const var p = Content.addPanel("P1", 100, 100)
p.set("width", 200);
p.set("height", 60);

const var k = Content.addKnob("Knob1", 50, 5);

k.set("parentComponent", "P1");

const var laf = Content.createLocalLookAndFeel();

laf.registerFunction("getModulatorDragData", function(obj)
{
	// set to true to make it not being clipped by the parent panel
	obj.alwaysOnTop = false;
    Console.print(obj.id); // bonus: you get the ID of the slider now too...
	obj.labelArea[2] += 10; // lol default width truncates label...

	return obj;
});

k.setLocalLookAndFeel(laf);

Let me know if there are any glitches - I had to fiddle around with the code until it respected nested parent structures, but rescaling, parentComponents etc. should all work consistently now.

ustk

@Christoph-Hart awesome! I was in the same situation so

z-ordering issue when using drawModulationDragger/drawModulationDragBackground

23

2.3k

13.6k

118.6k