Sluggish controls rendered over opengl context


#1

I'm a relative novice with Juce and recently have started using it for 3d surface rendering within a basic GUI. I am using Juce on Windows XP.. 

I have recently come across an issue that I am hoping someone can help me wth, A component such as a combo box that renders over a rapidly refreshing component rendered using an opengl context responds in a very sluggish way to interactions. You can see this in the opengl demo - click one of the the drop downs and see the latency in the displayed item selection as you move the mouse up and down.

This doesn't happen on a component with software rendering. Is there any way to prevent this or is it unavoidable?

Any assistance would be much appreciated!

Thanks,

Ivan


#2

I'm seeing nothing like that on my machine (OSX).. Could be that if you're on XP, the event loop is behaving differently, perhaps getting starved if the GL rendering is eating all the CPU time?


#3

I get this on Windows 8.1 too. Noticeably better with the software renderer.  Perhaps unsurprisingly, the difference is more noticeable on my old i7 laptop than my Xeon/Quadro equipped DAW.


#4

Thank you Jules for your reply and Andrew its interesting to hear you are also seeing something similar. 

I have found that if you turn off continuous repainting so that the window is not updated very often then the problem is reduced.  In terms of the event loop being starved the component I don't believe this is the case however I will profile this just to make sure. 

Can I ask a further basic question? In a component using opengl rendering is this not done on a background thread and is this still the case if you derive from OpenGLRenderer and use the renderOpenGL() method?

 


#5

So, I checked and the GPU rendering is taking almost no time - in fact even without rendering anything in Paint() but with continuous repainting enabled I get the same issue. Also, if I have another adjacent component that uses software rendering then the combo box behaviour is fine on this but not on the opengl rendered one. 

I think the problem is related to how the two components are interacting with regard to being painted since I also tried an experiment where I obscured the opengl component with a window that always stays on top i.e. task manager. If task manager is positioned, obscuring the opengl component, so that the combo box only intersects task manager then the interaction stops being sluggish. If you slightly lower task manager so that a few pixels of the opengl window intersect with the combobox then the behaviour becomes sluggish again.

Its probably worth me mentioning another observation that led me to seeing this issue since they may be related. I found that if you have your juce program minimised on the toolbar and click on it to maximise it back up then any opengl rendered components don't get resized() or paint() called at all but the software rendered ones do. Hence the opengl regions are not refreshed. This is why I turned on continuous repainting and hence saw the original issue. The only time with an opengl rendered component where the response of an overlapping component is OK is when the opengl window has continuous repainting turned off and the opengl context is not being refreshed with new data, hence I presume it is not being repainted.

So, sorry for the very verbose mail but I hope this gives some clues to the nature of the problem and how it might be fixed or worked around.

Thanks,

Ivan


#6

I've sorted out the repainting when a window is un-minimised now, but really can't see any performance problems on my machine. If anyone can do some profiling and identify exactly where the bottleneck is, let me know.


#7

Thanks very much for the update - that helps a lot! I'll try the profiling at some point and report back.