Базовое изображение с GLKView

Мне было трудно найти какие-либо примеры того, как правильно использовать Core Image с GLKView, чтобы плавно отображать «рецепты» Core Image в ответ на вводимые пользователем данные. Итак, после прочтения Руководства по программированию основных изображений и GLKView справочник по классу , Я придумал подход, который работает. Однако я не уверен, что это действительно так, поэтому я надеюсь, что кто-то может подтвердить, что это нормально, или указать мне лучшее направление.

Прямо сейчас я использую GLKView с GLKViewController. GLKView делегирует рисование своему родительскому контроллеру представления, который реализует glkView:drawInRect:. Метод рисования делает это:

- (void)glkView:(GLKView *)view drawInRect:(CGRect)rect {
    // make glkView's background light gray instead of black
    glClearColor(backgroundRGB, backgroundRGB, backgroundRGB, 1.0);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    // a custom object that holds a reference to a CIContext
    ImageEditingContext* context = [ImageEditingContext getInstance];

    // apply a core image recipe
    CIImage *outputImage = [context getFilteredPreviewCIImage];

    // draw the image
    CGRect inRect = outputImage.extent;
    inRect.origin.y = (self.glkView.contentScaleFactor * self.glkView.frame.size.height - inRect.size.height) / 2.0;
    [context.coreImageContext drawImage:outputImage inRect:inRect fromRect:outputImage.extent];
}

В частности, меня беспокоит последняя строка, [context.coreImageContext drawImage:outputImage inRect:inRect fromRect:outputImage.extent]. Допустимо ли вызывать этот метод из glkView:drawInRect:? Как я упоминал ранее, этот подход, кажется, работает нормально, но я стал подозревать его после запуска шаблона OpenGL ES Analysis Instruments. Он пометил строку с этой проблемой:

Использование многоконтекстного буфера рендеринга без сброса: Renderbuffer # 2 - ваше приложение использовало объект рендербуфера, который был обновлен в другом контексте без последующей операции сброса.

Мои GLKView и CIContext оба настроены с одним и тем же EAGLContext, поэтому я не совсем уверен, о чем идет речь в сообщении об ошибке. Любое понимание очень ценится!


ios objective-c core-image opengl-es glkview
person gilby    schedule 01.03.2014    source источник
comment
Насколько я могу судить, ваш код настолько хорош, насколько это возможно. Как вы отметили, вы создаете контекст CI из того же контекста GL, в котором отрисовывается ваше представление, и это предупреждение конкретно относится к действиям, предпринятым в другом контексте. Я предполагаю, что CI создает свой собственный частный контекст GL (используя ту же общую группу, что и контекст, который вы передали), выполняя всю свою работу там, а не сбрасывая, когда это сделано. (Ewww.) Сообщение об ошибке может быть хорошей идеей.   -  person rickster    schedule 04.03.2014
comment
Спасибо за внимание, @rickster! Я запишу ошибку.   -  person gilby    schedule 12.03.2014
comment
@gilby Вы когда-нибудь выясняли, в чем дело. У меня такая же проблема для примерно того же кода.   -  person otusweb    schedule 16.06.2017
comment
@otusweb Я этого не делал, но я перешел на Metal, который намного быстрее!   -  person gilby    schedule 27.09.2019

Ответы (1)


arrow_upward
0
arrow_downward

Я успешно сделал это с помощью glkview. Он автоматически настраивает буферы с помощью представления, поддерживающего OpenGL. Вам вообще не нужен буферный код, на самом деле glkview требует около 3 строк кода при правильной настройке. Приложение сбивается с толку, поскольку оно автоматически настраивает буфер для вас, затем вы создаете второй и не сбрасываете его для каждого кадра, вызывая множество проблем с памятью. Похоже, вы также создаете несколько контекстов, что тоже недопустимо. Прочтите руководство по программированию CIImage. У меня есть UISlider, который настраивает изображение в реальном времени с помощью glkview. Все, что вам нужно сделать, это инициализировать glkview, bindDrawable, drawImage из CIContext. Убедитесь, что ваш CIContext инициализирован с помощью EaglContext. В одном вы правы .... документации не существует. Удачи.

person Frank Underwood    schedule 17.12.2014