New issue mac starling demo (VM)

#1

When I tried to compile my project on mac OS X VirtualBox, it crashes, giving me a openGl error.
So I tried the starling Demo again and the same thing happens.
I use the latest Lime and Openfl dev build from github and I did rebuild Lime.
This is not happening on windows, could it be the VM ?

Here is the error :
Starling.hx:461: [Starling] Initialization complete.
Starling.hx:462: [Starling] Display Driver: OpenGL Vendor=Apple Inc. Version=2.1 APPLE-11.0.7 Renderer=Apple Software Renderer GLSL=
Called from ApplicationMain::main ApplicationMain.hx line 79
Called from ApplicationMain::create ApplicationMain.hx line 111
Called from *::_Function_1_1 haxe/Timer.hx line 244
Called from starling.core.Starling::initialize starling/core/Starling.hx line 451
Called from starling.events.TouchProcessor::set_simulateMultitouch starling/events/TouchProcessor.hx line 374
Called from starling.events.TouchMarker::new starling/events/TouchMarker.hx line 32
Called from starling.events.TouchMarker::createTexture starling/events/TouchMarker.hx line 93
Called from starling.textures.Texture::fromBitmapData starling/textures/Texture.hx line 264
Called from starling.textures.Texture::empty starling/textures/Texture.hx line 470
Error : Error calling openGL api. Error: GL_INVALID_ENUM

And haxelib list
actuate: [1.8.7]
box2d: [1.2.3]
crashdumper: git [dev:/usr/local/lib/haxe/lib/crashdumper/git]
extension-steamworks: git [dev:/usr/local/lib/haxe/lib/extension-steamworks/git]
format: [3.3.0]
hxcpp: [3.4.64]
hxtelemetry: [0.3.5]
layout: [1.2.1]
lime-samples: [4.0.1]
lime: 4.1.0 git [dev:/usr/local/lib/haxe/lib/lime/git]
mime: [0.0.1]
nape: [2.0.20]
openfl-samples: [4.9.0]
openfl-xinput: git [dev:/usr/local/lib/haxe/lib/openfl-xinput/git]
openfl: 5.0.0 git [dev:/usr/local/lib/haxe/lib/openfl/git]
starling: [1.8.10]
swf: [2.3.1]
zame-particles: [1.0.3]

Thanks for your help.

#2

It actually happens only in debug mode. I can compile and run with a release build.

#3

Debug mode checks for GL errors, and exits out if it encounters one.

What version of Lime and OpenFL are you running?

#4

The last dev version from Github for both.

#5

It is possible that there is an OpenGL error occurring somewhere else (through the OpenFL render code) or somewhere we do not care about. context3D.enableErrorChecking () is enabling this behavior, and perhaps Starling enables this on debug builds?

#6

I wonder if the error is really caused by the call here, or if it is caused earlier. Adding gl.getError () in advance of the GL calls there will clear out any past errors, so we can know whether the GL error is really throwing here or not, to know the source of the error