Hi Jesse,

Thanks for your point. I can confirm that the fbo extension is available there for this functionality, and there is no such error messages when call the same function in other clutk test cases.  And yes, the run-time check for the fbo capability is not implemented, it is assumed that this extension is supported by default now (It should not be a problem for opengl es2.0 driver with fbo extension supported, I think).

Regards,
Jammy

On Wed, Sep 15, 2010 at 5:22 AM, Jesse Barker <jesse.barker@arm.com> wrote:
Jammy,

With respect to the CheckGLError assertion in test-clutk-perf, assuming
that glGetError is called per OpenGL entry point (i.e. you are not
seeing an error triggered by another call), the only way you should be
seeing an invalid operation when setting framebuffer binding(s) back to
the default (glBindFramebuffer(GL_FRAMEBUFFER, 0)) is if the framebuffer
object extension functionality is simply not there (your OpenGL or GLES
implementation is too old).  I notice that the 'WITH_GLES' paths have
fewer checks for capabilities.  Is it possible that the code is simply
not checking at the moment?

cheers,
Jesse

On Tue, 2010-09-14 at 17:23 +0800, Jammy Zhou wrote:
> Hi Alexander,
>
> On Tue, Sep 14, 2010 at 4:31 PM, Alexander Sack <asac@linaro.org>
> wrote:
>         On Tue, Sep 14, 2010 at 9:38 AM, Jammy Zhou
>         <jammy.zhou@linaro.org> wrote:
>         >
>         > Issues Fixed:
>         > + Normalize clutter vetex positions to adapt to the vertex
>         shader
>         > + Use GL_TRIANGLE_FAN to implement original used GL_QUADS
>         primitive, which
>         > is not supported by gles2
>         > + Comment out cogl_flush() call in some functions (such as
>         > ctk_effect_blur_paint) to make sure following gles2
>         rendering can be shown
>         > + Fix render to cached texture problems
>
>
>         very nice.
>
>         is the cogl_flash call comment something we want to keep or
>         does that
>         show an underlying issue we should try to fix?
>
> [jammy] Because cogl_flush is implemented based on fixed pipeline, if
> we want to really fix it, we may need to use cogl for gles2 support in
> clutk, I think. So I just comment out them in some proper places for a
> workaround.
>
>
>
>         >
>         > Issues Left:
>         > + run test-clutk, there is crash at
>         "/Effect/Animation/Animation" test
>         > suite. This issue has already been reported by Alexandros,
>         see
>         > https://bugs.launchpad.net/clutk/+bug/614415, and it should
>         be an upstream
>         > problem.
>
>
>         neil replied in the other mail thread and has a patch for
>         clutter that
>         we should try. maybe see if that helps
>
> [jammy] I have tried the patch from Neil, and it works, but now there
> is the same issue for glBindFramebuffer as mentioned below at
> "/Effect/Animation/Signals" test suite when run test-clutk.
>
>
>
>         > + when run "test-clutk-perf 0 10 125 5 single animated blur
>         0.3.2 GMA950 2.1
>         > 1 10", crash happens with following error message. The error
>         happens when
>         > call glBindFramebuffer (GL_FRAMEBUFFER, 0).
>         > Clutk-WARNING **: [CheckGLError] GL_INVALID_OPERATION error
>         in File
>         > ./ctk-render-target.c at line: 581
>
>
>         Is this a regression from our gles port? e.g. if you run the
>         same
>         command with desktop gl does it work?
>
> [jammy] This is a regression from our gles port.
>
>
>         > + the actor painting (i.e, "paint_func(actor);" in
>         ctk_effect_blur_paint)
>         > seems independent from other gles2 rendering, and it is not
>         rendered into
>         > cached texture for later display. This means that we cannot
>         add special
>         > effects to the actor.
>
>
>         Do you think its a bug that it is independent from other
>         rendering?
>         what happens if we try to fix this?
>
> [jammy] I think it is not a bug, but incompatibility between cogl
> rendering and our gles2 rendering.
>
>
>
>
>         --
>
>          - Alexander
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev


--
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.