OpenGL on Intel Graphics chips

Hi Jules.


I have come across a problem with 2D OpenGL rendering. When I use the built-in graphics chip on my Windows 7 PC (Intel HD Graphics P4600), OpenGL renders some very strange results. I have replicated this with the Juce Demo, where 2D rending fails (see the attached image) but 3D rendering is completely fine.

I have checked on another machine running an Intel HD 4600 (not P4600...) and the problem is not present, so I suspect it is something specific with this chip.

I have checked and can render OpenGL graphics using other software, it only seems to be Juce which is effected.


Any help would be appriciated.




There were some issues before with Intel chips.

I know I had some strange issues at the time but I never tracked down why or if it went away (I upgraded shortly after).




Thanks for your response. It seems in that thread that Jules suggested the fix was to up the value of the numQuads enum in juce_OpenGLGraphicsContext.cpp.

If I change this value from 256 to 8192 the issues (mostly) go away, but I'm concerned that this value was set so low for a reason, would anybody know what the downside would be of having this value much higher than 256?




Higher values make rendering much faster, but IIRC there were bugs in some GL drivers that caused crashes when the buffers were too large, and there was no way I could find of detecting what was a safe size for a particular driver.

Hi Jules,


Was the issue you mention related to a particular chip or was it a particular driver on many chips?

Could you give me the details so I can investigate a little more and see if I can come up with a solution to my original problem?




Can't remember the details, I'm afraid - it was a problem with some drivers on my MS Surface, but I think it was fixed in later versions of Windows.

Looking through the commits in the Juce git repository I noticed that you did actually remove this fix some time ago, levaing the numQuads value set to 256 for both Windows and Mac. Since the original problem was fixed in Windows (i.e. the crashing Surface), is it not safe to return to the value of 8192 as it was before (from 19 Dec. 2011)?

Actually, that was a different reason - I think that was the GL drivers on an old version of Parallels that wasn't working. Again, I think that's something that was fixed in later versions. Amazing how flaky some of these drivers are.

It really is!

Going back to the original problem, do you know of any solution which could fix this drawing issue for me?

Or perhaps you know of some OpenGL method which can report whether it has drawn successfully (a long-shot, I suspect!), which I can use to switch off the use of OpenGL in the event of a problem like this?

Impossible for me to tell what's going wrong from that picture, you'd need to try removing graphics calls until you can narrow-down exactly which ones are failing. But in my experience of these things it's often impossible to figure out exactly what it is that the driver is having a problem with.



Please check latest drivers. They fix 2D rendering issues you observed in JUCE Demo.

Let me know if you have further concerns.



Tomasz Sulek

Intel Corp.

Thanks Tomasz - JUCE can now render OpenGL properly on my Surface Pro 3 again!

Tomasz, thank you for passing along the update to me, I really appreciate it.


Just to let you know that I have upgrade my drivers from to and this has 100% fixed the issue.


Thanks again,