using a TextVisual leads to unintended scaling of other Visual

[bollu]

I'm not sure if creating an issue is the right thing to do, but I haven't been able to debug this, so I decided to go ahead and just create one.

The problem is that when I use a TextVisual with multiple strings (as the constructor allows, it throws off the scaling completely and causes the entire scene to become really tiny. I don't know why this happens.

Also, it does not happen if you have a TextVisual with just one string. This to me is even more perplexing.

_Example of extreme scaling down:_

example in which this happens

offending line of code

_Proper rendering with one TextVisual_

[larsoner]

So you have this problem with using a single TextVisual with a list of two positions and a list of two strings. Does it happen if you make two text visuals, one with the first position and string, and the other with the second position and string? Can you turn it into a minimal example (e.g., using as few lines as possible on current master branch)? That would help isolate the problem.

[bollu]

@Eric89GXL: here is a minimal gist

_what it looks like initially:_

_what it looks like after pressing a key twice on the keyboard_

It's funky, because, here's how the code works:

1. Don't render the ticks
2. Press a key - this renders the ticks. They don't show up onscreen, but the other TextVisual stays all right
3. Press a key again - this should disable the rendering of the ticks. But, when you do this, the transform goes nuts and the TextVisual shrinks to nothing.

This is weird. My expected behavior would be that it shrinks immediately after I press a key.

I have a feeling I'm missing something very obvious here :/

[larsoner]

So the TextVisual under the hood actually does its own rendering to create each glyph. This rendering occurs on an offscreen buffer, so it queries the OpenGL state before actually rendering. I have a feeling there are some delayed GLIR queues causing problems where the state is queried and set incorrectly here.

Things to probe:

1. Does it still fail for you if the second TextVisual object is actually only a single string and single position, or does it need to be two? This will help determine if it's actually something about the dual rendering that's a problem.
2. Does it fail if you a) use the same string for all three text bits and b) pass the font_manager property from the first TextVisual to the second one? This will help determine if it's due to the changing GL state, since using the same font_manager will make it so it doesn't need to render for the later text objects.

[bollu]

@Eric89GXL I'll try both and get back

[bollu]

@Eric89GXL It works perfectly if the second TextVisual also renders just one string

[larsoner]

interesting... I wonder if I did something stupid with the concatenation and position setting. If you have time to investigate (e.g., by adding some debugging print statements at various places in the text visual generation and drawing code) please do otherwise I can look tomorrow.

[bollu]

@Eric89GXL, I'll try and do it once I finish up the colorbar. I need to learn how to do the right coordinate transforms for it for the pixel width border!

[larsoner]

Cool. For now then, just use two TextVisuals in your ColorbarVisual so you can wrap that up, and add a note saying that they should be combined once this issue is closed.

[bollu]

all right.

also, once AxisVisual gets merged, we can use that, correct?

[larsoner]

Yeah, but it blows up Luke's system, so don't wait for that. And we'll probably also need to modify it to e.g. allow actually setting what the ticks should be, or the number of ticks. Right now it is basic and just always does 10 spanning the full range of the axis, which might not be great for a colorbar.

[bollu]

@Eric89GXL hm, okay then, I'm constructing two TextVisuals in that case with a URL to the issue, so that it can be fixed later.

[nippoo]

This might be related to #975.

Is there any progress on this issue? It's been bugging me too...

[larsoner]

No, we need to get #928 in before we can make additional progress on these issues. Some of them will be fixed, some won't. But the systems have been changed there so we need to make the fixes to that. If you have time, you could help @campagnola and @bollu port visuals in the new system, which would get us closer to fixing this.

[campagnola]

Just fixed a bug in #928 where TextVisual was changing the glViewport; hopefully that's it.

[larsoner]

Yeah that's probably the culprit. But it needs to change it during rendering of SDF. Can you point to the change? I'm curious how you fixed it.

[campagnola]

See the most recent commit.

[larsoner]

I guess I should have just looked at the commits, sorry about that... looks like flushing at a different point in the code. I bet it will fix this.