Glitches with OpenGL on HTC Desire


#1

Testing my app on an old HTC Desire I get some crazy graphical glitches. This only happens when OpenGL is switched on, via 

​openGLContext.attachTo (*getTopLevelComponent());

in Main.cpp.

This only happens with this device, my only other current test device is a Samsung Galaxy Ace 2, which works fine with OpenGL. 

I loaded the JUCE demo and managed to recreate the glitches. As soon as I switch to the OpenGL 2D demo everything goes haywire. Once this happens the rest of the demo is also glitchy.

Also - starting the OpenGL 3D demo crashes the app completely. 

Screenshots below:

P.s. would be nice to have working attachments for forum posts! 


#2

Hmmm this definitely looks strange. Which android version are you using? Any versions before 2.3 are known to have massive opengl issues. Also, some opengl drivers (such as older intel drivers) have an issue if there are too many vertices in the buffer. Try changing the numQuads variable on line 1225 in modules/juce_opengl/opengl/juce_OpenGLGraphicsContext.cpp to something smaller - maybe to 16 or so. Any luck?


#3

Thanks Fabian - the Android version is 2.6. I will have a tinker with the numQuads variable as you suggest and see if that makes a difference.

I remember running the OpenGL demos without problems when I first tried on this phone around 6 months ago. I'll see if I can track which version that was and see if it behaves differently. 


#4

Just compiled with `numQuads = 16`. Behaviour is slightly different: I get blank screen for about 5-10 seconds, then the glitched graphics appear. The OpenGL 3D demo still crashes. Screenshot below.

 

UPDATE: I compliled version 3.05 to see if that was any different. I still get the glitchy OpenGL 2D demo but the 3D demo works fine, does not crash. Also with this JUCE version, if I press the "Menu" button on the device it redraws everything OK, but on the next response from a touch event it glitches out again. This is different to the latest JUCE, where it seems to crash or not recover. 

I also installed a few different Open GL demos on this phone and none exhibit this behaviour. That may also be because incompatible apps will not be visible on the app store for the HTC Desire. 

 


#5

I've done some initial debugging on this and it seems that some OpenGL calls are not done on the rendering thread. At least this is what adb logcat is complaining about. Android strictly wants all OpenGL calls to come from the thread that created the OpenGL context and JUCE should be respecting this. I'll look into this more closely next week.


#6

Sorry to be a broken record on this thing, but I wonder if what you are seeing is related to what I discussed here:

  http://www.juce.com/forum/topic/ondraw-happening-all-time?page=1

In that situation, the rendering path got called when it really shouldn't have.  My fix to the the java code was not introduced to Juce yet AFAICT.  I never submitted any patch because I have a lot of other mods in my java activity too.


#7

I don't think its the same issue - I have a similar modification in my Java activity based on your suggestion, to try and improve touch responsiveness. I believe Fabian and JUCE team are planning to look at the draw / touch performance issue. 


#8

Yes, I am currently looking at this. Fixing some other related issue along the way. Might still take a bit though.


#9

Just a quick update on the progress of fixing this bug: as far as I can tell, on my test device (Samsung Galaxy Nexus), OpenGL in JUCE currently has three separate bugs which may cause the broken OpenGL drawing you are seeing. Here is a list with possible workarounds:

1) Colours are inverted: this is fixed on the latest tip

2) Scaling (via setGlobalScalingFactor or setComponentScale) is broken when used with OpenGL: this bug will appear as torn graphics on some devices (similar to your screenshot): this is now fixed on the latest tip

3) Android will delete your OpenGL context when your app is put into the background. When the app is re-opened, android will supply JUCE with a new OpenGL context and JUCE will delete any resources associated with the old context. Unfortunately, in the process of tearing-down the old context, JUCE will call several gl calls to delete resources, which will fail as the context has already been deleted by Android. For some odd reason, these OpenGL errors will cause any further drawing on the new context to fail. It seems that some device put the context into an error state once an OpenGL error occurs and will refrain from drawing after that. We are still investigating this and working on a fix. As a workaround, if you are devloping a pure OpenGL app and do not use any JUCE components, then simply refrain from calling any gl calls intended to delete OpenGL resources when your context is deleted. 

I hope this helps!


#10

I'm using the openGL renderer, and otherwise all juce GUI.

I have users with the HTC One reporting the crazy glitching as shown above after upgrading to Lollipop on their devices but not before. As far as I can tell this very specific glitching has only been reported to occur on those devices and only running lollipop.

I had previously noticed that the setGlobalScalingFactor does not work right, but have had success setting the scaling on the main component without issues (but have to avoid popup menus, comboxes, etc).

As for dealing with the GL context on app suspend and resume, I seem to have hit upon a sequence of events that prevents most issues you seem to be referring to in #3... mainly by detaching the GL context at the application suspend callback, and reattaching after the resume callback (but on a timer so that about 300ms passes before reattaching. Obviously, this kind of approach is not fool-proof and is clearly a band-aid for something deeper going wrong.

I have a feeling that something else is going on with respect to this particular issue on HTC devices...


#11

Any progress on item 2)? How close is the development branch to being pushed?

 

HTC One on Lollipop is definitely having issues. I have hundreds of devices but not this one, however we have multiple customers having the glitch issues on Lollipop 5.0.2.


#12

Same situation here. It looks like I'll need to get a hold of an HTC device to try to troubleshoot this myself.


#13

Item 2 (android scaling support) was fixed with this commit


#14

Now getting reports of the GL-renderer graphics glitch-fest on samsung devices running android 5.1.1.  Will investigate further in about a week.

 


#15

Same here with Samsung and HTC One devices. I have been unable to reproduce the issues so far. Will update as I find out more info


#16

Here is my progress so far.

 

I currently own the HTC one US, HTC One International, Galaxy S5 TMobile. Out of those the HTC One international and Galaxy S5 Tmobile show the problems and its really odd. I personally think its a driver issue and have ways around it that works on all the other devices but its a dang hack.

 

There are 2 possible fixes and both essentially do the same thing (and make no sense). In juce_OpenGLGraphicsContext.cpp::add (const int x, const int y, const int w, const int h, const PixelARGB colour) noexcept in the end of the code you can change:

 

if (numVertices > numQuads * 4 - 4)

to

if (numVertices >= numQuads * 4 - 4)

 

Or the other option is to add 1 extra value onto the vertexData data by changing VertexInfo vertexData [numQuads * 4]; to VertexInfo vertexData [numQuads * 4 + 1];

 

Both of these things do almost the same thing. They make it so there is an extra vertex value uploaded to the vertex buffer that is never used. Why it works I have not quite figured out yet. I have other code that draws sprites using very similar techniques and I have not run into this issue as the standard VBO works fine and I do not need to do this 'hack'.

 

Changing the numQuads does nothing. You can put it at 2 and as long as you allocate 1 extra for the vertex data it will still render correctly (albeit slow). But put it back to vertexData[numQuads*4] and it does not render correctly.

 

I personally do not like not really knowing what is going on so any thoughts on this subject would be greatly appreciated. Worst case this is going out as a short term fix (hack) as we have hundreds of customers with this issue right now.

 

(I would have had this earlier but the current github doesn't build for Android so I had to make a few tweaks. My version of Juce is very different than the current github so I had to check out so we are all talking about the same thing). Getting so tired of all the Android inconsistencies... almost as bad as getting OpenGL on windows in a stable fashion....

 

Michael


#17

Thanks Michael. I've still been struggling to get a device that reproduces it... I purchased a used HTC One and need to upgrade it to 5.1.1 with a windows PC (windows in virtualbox aborts when connecting one).

At least I can do this to push out as an emergency fix if I never get it reproduced locally.

 


#18

HTC One only exhibits the behavor on 5.0.2. Once you go to 5.1.1 it fixes the issue. The interesting thing that I learned is the GPU driver in the HTC One 5.0.2 is the same one in Samsung Galaxy S5 5.1.1. Really wondering if this is an Adreno driver bug at this point.


#19

Thanks for that tip, the HTC I have here is back on 4.1....  I actually don't know what specific android lollipop version the latest ROM software I was trying to install on it will be. 


#20

Interesting, implementing either option of your fix causes a particularly active part of my app to be *much* slower on my galaxy note 4 (which doesn't have the glitching). It doesn't make sense, in the first case it just means glBufferSubData and glDrawElements is updating/drawing 1 less quad than the full VBO in memory, but the performance difference is dramatic in my case. What the hell?