I’ve been putting JUCE through its paces over the last couple of days with a view to using it for a commercial product. I’m mainly interested in iOS, OS X and Windows with OpenGL right now so I have been focussing on those areas using the JUCE demo.
I’ve noted down a few issues which I thought I should share, sorry if they sound picky but I need to prioritize quality and I found them all pretty quickly:
iOS retina devices - OpenGL renderer shows everything at x2 zoom - this has just been fixed in the latest tip so I won’t go into it any further
iOS OpenGL renderer performance example 1
Run JUCE demo (release build) on an iPhone 3GS in portrait
Select Graphics Rendering/Paths - Linear demo
Select software renderer - observe that it runs around 18ms/frame
Select OpenGL renderer - observe it runs at around 15ms/frame, but with long (200-1000ms) stutters and freezes in between each frame
iOS OpenGL renderer performance example 2
Run JUCE demo (release build) on an iPhone 5 in portrait
Select Graphics Rendering/Glyphs demo
Select software renderer - observe that it runs around 2ms/frame
Select OpenGL renderer - observe it runs at around 7ms/frame
iOS Webview is black when using OpenGL
Run JUCE demo on any iOS device
Select Web Browser demo
Select software renderer - everything looks fine
Select OpenGL renderer - webview is black
iOS File choose dialogues have incorrect layout
Run JUCE demo on any iOS device
Select Widgets demo
Tap on ‘click for a popup menu’
Choose ‘File chooser dialogs’ and then any dialog
Dialogue is stretched across a large area and it’s not possible to exit
Menu drop downs don’t handle orientation changes well
Edit JUCE demo to support all orientations and run it on any iOS device
Select Widgets demo
Tap on ‘click for a popup menu’
Choose ‘File chooser dialogs’ (to get the child drop down menu)
Change orientation (worst going from portrait->landscape) - observe that dropdown and child dropdowns don’t move/resize
This final one is on Windows rather than iOS:
Dropdown menus not visible when Windows JUCE Demo maximized on second monitor, using OpenGL renderer
Thanks, yes, I know that iOS (and android) need some optimisation to get GL running smoothly. It’s on my to-do-list!
Can’t replicate your Windows problem, but I’m using Parallels, and its multi-monitor mode may not be very good. When you say the menus don’t work, what exactly goes wrong? Does it make a difference if you use a native title bar for the window?
With regards to the Windows multi-monitor issue, if I use the native window title bar then everything works as expected.
By ‘not working’ I mean ‘not visible’ - they can still be clicked on so it’s a rendering issue. Slightly more detailed repro:
Run JUCE Demo on Windows (debug or release)
Disable native window title bar (ie. use the JUCE one)
Enable OpenGL renderer
Select the Graphics Rendering/Paths - Solid demo
Drag JUCE Demo to second monitor and maximize
Click on Demo or Look-and-feel menu items - the dropdown does not appear, but it can still be clicked on
Click on ‘Test type:’ combo box - the dropdown does not appear, but it can still be clicked on
Sorry to put the words ‘multi monitor issue’ in the same sentence, sounds like a bitch to debug if you can’t reproduce. I’m using a an ATI Radeon HD 5800 series if that helps - ie. not some integrated graphics nightmare!
Hmm difficult for me to add much more to this because it would appear to be a system specific issue, but when stepping through the code I did spot that the pop up menus for the menu and the combo box appear to be using the software renderer, whereas other (visible, working) components are using the OpenGL renderer. For example, a breakpoint on LookAndFeel::drawPopupMenuBackground() shows that the call to g.fillAll() goes to the software renderer. This might be a red herring since I’m new to this code and I notice that the software renderer is still heavily used for many aspects of the UI even when the OpenGL renderer is enabled.
Maybe this statement is true : Components rendered OpenGLContext::CachedImage::renderFrame() (and hence using the OpenGL renderer) are visible, components rendered from ComponentPeer::HandlePaint() are not.
Well, the GL renderer is indeed only used in windows where it’s been actively turned on, so in the demo, just the main window. Any popups will just use the default renderer.
If the GL rendered window failed to draw under some circumstances, I wouldn’t be overly surprised because it’s fairly new code, but for a standard window to not draw would be very strange indeed, because those things have been solid for many years…
Is there likely to be any progress on these iOS bugs in the immediate future? We got a bit sidetracked on the dual monitor Windows issue but to be honest that’s the least of my worries.
All of these are easily reproducible ‘out of the box’. I could delve in when I get some time, but to be honest my intention behind using a 3rd party library was to not have to do that sort of thing if at all possible!
I’m buried under a tracktion-shaped mountain of work at the moment, so don’t know when I’ll have enough mental energy to look at iOS myself. Other people are using it though, anyone else got a clue about this?