On 15.09.2015 09:54, Gerd Hoffmann wrote:
>   Hi,
> 
>>> +    scon->scanout_mode = scanout;
>>> +    if (!scon->scanout_mode) {
>>> +        if (scon->fbo_id) {
>>> +            glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
>>> +                                      GL_COLOR_ATTACHMENT0_EXT,
>>> +                                      GL_TEXTURE_2D, 0, 0);
>>> +            glDeleteFramebuffers(1, &scon->fbo_id);
>>
>> I'm not sure, but maybe the framebuffer itself should be unbound here,
>> too? (i.e., glBindFramebuffer(GL_FRAMEBUFFER, 0))
>>
>> I know it's deleted but I don't know whether that's enough.
> 
> Fixed.
> 
>>> +    glBindFramebuffer(GL_READ_FRAMEBUFFER, scon->fbo_id);
>>> +    glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
>>> +
>>> +    SDL_GetWindowSize(scon->real_window, &ww, &wh);
>>> +    glViewport(0, 0, ww, wh);
>>> +    y1 = scon->y0_top ? 0 : scon->h;
>>> +    y2 = scon->y0_top ? scon->h : 0;
>>> +    glBlitFramebuffer(0, y1, scon->w, y2,
>>> +                      0, 0, ww, wh,
>>> +                      GL_COLOR_BUFFER_BIT, GL_NEAREST);
>>
>> Should we bind the FBO back to GL_DRAW_FRAMEBUFFER after the blit operation?
> 
> Isn't READ/DRAW used for framebuffer blits only?  Normal rendering goes
> to GL_FRAMEBUFFER I think ...

http://docs.gl/gl4/glBindFramebuffer says: "Calling glBindFramebuffer
with target set to GL_FRAMEBUFFER binds framebuffer to both the read and
draw framebuffer targets.", so to me it looks like GL_FRAMEBUFFER is
just an alias for GL_{DRAW,READ}_FRAMEBUFFER at the same time.

Max