OpenGL 3.2 VAO creation fails on OS X Maverick - macos

I have a program which used to work fine on MAC OS X Lion.It uses OpenGL 3.2 Core profile.Now after I upgraded to Maverick it fails on glGenVertexArrays() right after context setup.The context is being created all right.What has changed in Maverick regarding OpenGL 3.2 setup?
I initialise the context like this:
static CGLPixelFormatAttribute attributes[4]={
kCGLPFAAccelerated,
kCGLPFAOpenGLProfile,
(CGLPixelFormatAttribute)kCGLOGLPVersion_3_2_Core,
(CGLPixelFormatAttribute)0
};
_errorCode = CGLChoosePixelFormat(attributes,&_pix,&_num);
if(_errorCode > 0){
throw ;
}
_errorCode = CGLCreateContext(_pix, NULL, &_context);
if(_errorCode > 0){
throw;
}
CGLDestroyPixelFormat(_pix);
_errorCode = CGLSetCurrentContext(_context);
if(_errorCode > 0){
throw ;
}
None of these throws an error till I am getting to VAO handle generation.Also glGetError returns some junk.
UPDATE:
I caught the error which is GL_INVALID_FRAMEBUFFER_OPERATION​, 0x0506 .And now it happens when I perform
glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
when no custom framebuffer is bound.If I call the draw command with custom FBO it does work.My context creation has no display.It is offscreen.Can it be that with the newer implementation Apple enforces display to exist in order to access default FBO? On Lion I did the same and it worked.Btw,the GL version is 4.1.

Related

glMapBufferRange returns null and produces a GL_INVALID_ENUM?

OpenGL ES 3.0 here. I am trying to read back the contents of a TRANSFORM_FEEDBACK buffer like this:
GLES30.glBindBufferBase(GLES30.GL_TRANSFORM_FEEDBACK_BUFFER, 0, tfo );
GLES30.glBeginTransformFeedback( GLES30.GL_POINTS);
GLES30.glEnable(GL_RASTERIZER_DISCARD);
GLES30.glDrawArrays( GLES30.GL_POINTS, 0, mNumVertices );
GLES30.glDisable(GL_RASTERIZER_DISCARD);
GLES30.glEndTransformFeedback();
int error1 = GLES30.glGetError();
Log.e("mesh", "begin, error="+error1);
ByteBuffer buffer = (ByteBuffer)GLES30.glMapBufferRange( GLES30.GL_TRANSFORM_FEEDBACK, 0, 4*mNumVertices, GLES30.GL_MAP_READ_BIT);
if( buffer!=null )
{
// use it
}
else
{
int error2 = GLES30.glGetError();
Log.e("mesh", "failed to map tf buffer, error="+error2);
}
GLES30.glBindBufferBase(GLES30.GL_TRANSFORM_FEEDBACK_BUFFER, 0, 0);
and the output is
E: begin, error=0
E: failed to map tf buffer, error=1280
i.e. it really looks like glMapBufferRange() generates error 1280, which Google tells me is GL_INVALID_ENUM.
Problem:
according to https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glMapBufferRange.xhtml, glMapBufferRange is never supposed to generate such error. Only GL_INVALID_VALUE, GL_INVALID_OPERATION and GL_OUT_OF_MEMORY ?
Of course glMapBufferRange can cause an GL_INVALID_ENUM error.
See OpenGL ES 3.2 Specification - MapBufferRange
An INVALID_ENUM error is generated if target is not one of the targets listed in table 6.1.
Note, this khronos pages are not the OpenGL (ES) specification. This pages are just for help and wiki purpose.
The enumerator constant GL_TRANSFORM_FEEDBACK is the target for the operation glBindTransformFeedback.
A valid target for glMapBufferRange is GL_TRANSFORM_FEEDBACK_BUFFER:
ByteBuffer buffer = (ByteBuffer)GLES30.glMapBufferRange(
GLES30.GL_TRANSFORM_FEEDBACK_BUFFER, 0, 4*mNumVertices, GLES30.GL_MAP_READ_BIT);

PixelBuffer operations doesn't work in Release build Qt5.6 MSVS2013

I'm trying to build Qt5.6 project in MSVS2013 express (i wrote all code under QtCreator in Linux). First of all in Visual studio it i could build it only in Release mode, and it works fine. Then i used windeployqt.exe utility for creating deployment pack. I also put assimp32.dll (i use it for model loading).
And everything works fine, except PIXEL_BUFFER functionality (I draw some stuff to texture in additional Framebuffer, make some analysis of drawing result, prepare another one texture and push it for drawing).
I've got some errors in Dependency Walker (msvcr90.dll, Dcomp.dll, API-MS-WIN-CORE-*.dll) even though i've installed every MS Redistributable crap that exist in this world.
Here the code that i try to use:
void AUVGBO::PrepareGBO(QOpenGLShaderProgram *shader) {
if (mEnabled) {
this->PrepareRender(shader, AUVCamera::PR_PROJECTION | AUVCamera::PR_VIEW | AUVCamera::PR_VIEW_POS | AUVCamera::PR_LIGHT | AUVCamera::PR_LIGHT_POS );
// Attach framebuffer for intermediate rendering
m_GL->glBindFramebuffer(GL_FRAMEBUFFER, mFBO);
m_GL->glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
m_GL->glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
m_GL->glViewport(0, 0, mGBO_Width, mGBO_Height);
}
}
void AUVGBO::FinishGBO(QOpenGLShaderProgram *shader) {
// Read pixels from FBO texture
GLuint indexAsync = mPBO_inIndex;
GLuint indexSync = (mPBO_inIndex + 1) % PBO_NUM;
// Bind pixel buffer for asynchronous reading from framebuffer
m_GL->glReadBuffer(GL_COLOR_ATTACHMENT0);
m_GL->glBindBuffer(GL_PIXEL_PACK_BUFFER, mPBO_in[indexAsync]);
m_GL->glReadPixels(0, 0, mGBO_Width, mGBO_Height, GL_RGB, GL_FLOAT, 0); // This call will be async
if (firstAsyncCalls && ( indexSync != 0 )) {
mPBO_inIndex = indexSync;
return;
} else {
firstAsyncCalls = false;
}
// Bind pixel buffer which already has data fetched one step ago
m_GL->glBindBuffer(GL_PIXEL_PACK_BUFFER, mPBO_in[indexSync]);
memcpy(mGBO_Pixels,
m_GL->glMapBuffer(GL_PIXEL_PACK_BUFFER, GL_READ_WRITE),
mGBO_Size * 3 * sizeof(GLfloat));
m_GL->glUnmapBuffer(GL_PIXEL_PACK_BUFFER);
m_GL->glBindBuffer(GL_PIXEL_PACK_BUFFER, 0);
// Swap buffer for sync/async readback
mPBO_inIndex = indexSync;
m_GL->glBindFramebuffer(GL_FRAMEBUFFER, 0);
so now every pixel in memory area [mGBO_Pixels : mGBO_Size * 3 * sizeof(GLfloat)] is black, but they should'not be black. I put (for test) 0.12345f value in third byte of every pixel
color = vec4(cos, length(r), 0.12345f, 1.0f);
but (mGBO_Pixels + 2) is 0.0 if i run exe file. But in VS everything is ok as i've already said ((mGBO_Pixels + 2) = 0.12345f).
I found some SO answers, where people said that it could be Qt openGL bugs (their application crashes on initializeGLContext() stuff), but in my situation pushing created texture to openGL is ok. So guess that i've made a mistake somewhere. It drives me crazy. huh. Wish Sara and John Conor with T800 go to Microsoft instead of Cyberdyne.
P.S. I create release build using Cmake in my Arch Linux, and everything work as Avtomat Kalashnikova, so at least in Linux Qt OpenGL stuff works. If i find enough time i will try to use Cmake with MinGW in Windows.

OSX 10.10 file change event from dispatch queue

I try to monitor file changes on OSX 10.10, starting with a fresh Cocoa application in Xcode, just adding the following code.
If I uncomment the last line in the snippet then I receive the file change events perfectly fine. But I can not make this last call because it should be a Cocoa GUI application.
I digged through a lot of documentation and can't find my error. Do I have to initialize or start this whole dispatch subsystem somehow?
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
int fd = open("<FILENAME>", O_EVTONLY);
if (fd == -1) return;
dispatch_queue_t qu = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
if (!qu) {
printf("can not get queue");
return;
}
unsigned long mask =
DISPATCH_VNODE_DELETE |
DISPATCH_VNODE_WRITE |
DISPATCH_VNODE_EXTEND |
DISPATCH_VNODE_ATTRIB |
DISPATCH_VNODE_LINK |
DISPATCH_VNODE_RENAME |
DISPATCH_VNODE_REVOKE;
dispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_VNODE, fd, mask, qu);
printf("source created\n");
if (!source) {
close(fd);
return;
}
printf("source valid\n");
dispatch_source_set_event_handler(source, ^{
printf("FILE CHANGED\n");
});
dispatch_resume(source);
printf("source resumed\n");
// If I call dispatch_main() I will receive the file system events as expected.
// But as a Cocoa application, I must not call this.
// Instead, I was under the impression that NSApplicationMain handles this.
//dispatch_main();
}
Grand Central Dispatch objects, such as dispatch sources, are automatically retained and released by ARC in recent versions of the compiler and frameworks.
At the end of your method, the last strong reference to source is lost and ARC is issuing an automatic dispatch_release(source). (It would also release the queue, but the source has another strong reference to that. So, if the source survived, so would the queue.)
You need to keep a strong reference to the source in an instance variable.

Android5.0 Bitmap.copyPixelsFromBuffer crash, "call to OpenGL ES API with no current context"

I want to save a view's snapshot to a file, but comes the error.
My code is as following:
View decor = ***; //
int width = decor.getWidth();
int height = decor.getHeight();
Bitmap bitmap = Bitmap.createBitmap(width, height, Config.ARGB_8888);
Canvas canvas = new Canvas(bitmap);
decor.draw(canvas);
int bytes = bitmap.getByteCount() + 8;
ByteBuffer buffer = ByteBuffer.allocate(bytes);
buffer.putInt(width);
buffer.putInt(height);
bitmap.copyPixelsToBuffer(buffer);
byte[] array = buffer.array();
but bitmap.copyPixelsToBuffer(buffer); will crash.
the error is like this:
12-09 08:36:43.107: E/libEGL(14642): call to OpenGL ES API with no current context (logged once per thread)
This error only happens on Android 5.0, are there any changes in the new platform? I know android 5.0 use a ThreadedRender to render a surface, how can I handle this problem? Thanks very much!!!
Even i am facing the same problem! It seems like in pre-lollipop version the context was leaking and is being used by default (I assume). But with lollipop it is strictly needed to create or pass the context explicitly!
hope these helps!
https://stackoverflow.com/a/27092070

Creative Gesture Camera in Processing

I'm trying to use the creative gesture camera in Processing. I started with the Intel Perceptual Computing SDK, and ran into an issue.
I want to get the hand openness, and I am running into some issues - no matter what, the hand.openness returns 0. It otherwise runs quite well...
Some Sample code I'm trying to get to work: If you open your hand it starts printing to the console, close it and it stops.
import intel.pcsdk.*;
PXCUPipeline session;
PXCMGesture.GeoNode hand = new PXCMGesture.GeoNode();
void setup()
{
session = new PXCUPipeline(this);
if(!session.Init(PXCUPipeline.GESTURE))
exit();
}
void draw()
{
background(0);
if(session.AcquireFrame(false))
{
if(session.QueryGeoNode(PXCMGesture.GeoNode.LABEL_BODY_HAND_PRIMARY|PXCMGesture.GeoNode.LABEL_OPEN, hand)) //Only when primary hand is open
{
rect(0, 0, 10, 10);
println(hand.openness + " : " + frameCount); //Openness should be from 0 to 100
}
session.ReleaseFrame();
}
}
Using the current version of Processing (2.0.3), Perceptual Computing SDK Version 7383.
Try updating the version of the SDK you're using if your project will allow it, there were quite a few bugs with getting attributes such as openess, openessState, radius, to name a few with the processing library (some attributes would even throw a null pointer exception when trying to retrieve them). I believe these have all been fixed in the recent versions, along with the inclusion of 64 bit processing support.

Resources