iOS issues found during JUCE evaluation

#1

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

  • Run JUCE Demo on Windows.
  • Drag JUCE Demo to second monitor and maximize
  • Enable OpenGL renderer
  • Drop down menus no longer work
#2

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?

#3

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!

#4

Very odd… Can’t reproduce that here, and can’t think what it could be… More clues required!

#5

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.

Conditions:

  • Windows (debug or release build)
  • Juce demo with OpenGL renderer enabled
  • Using Juce title bar
  • App maximised on second monitor
  • On my system only (!)
#6

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…

#7

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.

There’s also this iOS touch bug : http://rawmaterialsoftware.com/viewtopic.php?f=4&t=10746

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!

#8

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?

#9

Come across any skeletons of previous climbers?

#10

Yes, there’s certainly a few bones scattered around up here!