On Tue, 2009-09-01 at 20:32 +0800, JiangWei Zhou wrote:
> 
> 
> On Tue, Sep 1, 2009 at 8:22 PM, Robert Bragg <[email protected]> wrote:
>         On Tue, 2009-09-01 at 12:18 +0100, Neil Roberts wrote:
>         > On Tue, 2009-09-01 at 01:01 +0000, jiangwei zhou wrote:
>         >
>         > >    we know that at present  the clutter's clipping is
>         implemented in
>         > > clip plane/stencil  buffer/Scissor.
>         > >
>         > >    using stencil buffer, we can implement  arbitrarily
>         ploygonous
>         > > clipping. it is one very common way to do the clipping in
>         gles.
>         > >
>         > >    but now ,we have a new demand to implement the clipping
>         without
>         > > stencil buffer . because in our target the clipping based
>         on stencil
>         > > buffer is very slow, unacceptable.
>         > >
>         > >    we consider two ways. i hope other guys can give me
>         some suggestion
>         > > or new idear.
>         > >
>         > >     1. if  only rect clipping is considered,can i clip the
>         actor in
>         > > fragment shader?
>         > >
>         > >         the clip arear is in object coordinates, can i in
>         fragment
>         > > shader , convert the fragment coord point from clip
>         coordinates to
>         > > object coordiantes ,then using rect including algorthim to
>         discard
>         > > those not in the area?
>         >
>         > If the clip region is a rectangle, Cogl should already
>         automatically use
>         > glScissor (if possible) or the clip planes if it is not a
>         screen
>         > rectangle. I think the clip planes and scissor rect should
>         be quite fast
>         > so there probably isn't any benefit to using a fragment
>         shader in this
>         > case.
>         
>         To say a bit more here; it's not only
>         cogl_clip_push_window_rect() that
>         will use glScissor. Even if you use cogl_clip_push() cogl will
>         look at
>         the modelview matrix to see if it represents an axis aligned
>         rectangle
>         and use glScissor when possible. Multiple rectangular clip
>         regions may
>         be pushed on to the clip stack, and the glScissor rectangle
>         will
>         correspond to their intersection.
>         
>         regards,
>         - Robert
>         
>         --
>         Robert Bragg, Intel Open Source Technology Center
>         
>         
>         
> 
> 
> hi, robert.
> thanks.
> glScissor is used for  window clipping, but i know it is only used for
> 2D clipping. 
> just to restrict render in one screen rect .
> but when the actor rotate in 3D space, it seems not correct,right?
> when the actor rotate in 3D space, even the clipping is rect, but in
> sceen coordinate , it cannot be clipped by 
> glScissor. 

right; if you want to clip to a rectangle in actor space and the actor
is rotated we can't use glScissor.

Both of your ideas sound like they could work to some extent, but my gut
feeling is that you may find they are both still very slow. I still
don't understand why clip planes don't work for the case where you are
clipping a rectangle in actor space?

Although you said you have very slow stencil buffer support on your
platform, it may be that your hardware doesn't support a stencil buffer
but your driver is internally using a multi-pass fallback technique
(like your texture based stencil buffer idea) so you may find that the
driver is already doing this but it may be more heavily optimized. On
the other hand the driver may be doing an extra render for every
primitive (e.g. triangle strip) whereas you would presumably only need
to do it once per actor paint so maybe you could get it to be faster.

Your first idea has potential to be faster (assuming you can't use clip
planes) because you are making assumptions that help simplify the
problem and it doesn't rely on multiply renders for each primitive.
Obviously it makes it awkward if you want to make use of fragment
shaders for other effects so you may need to implement some kind of
framework to handle some runtime shader combining. The requirement to
calculate the inverse projection though and multiply by that for each
fragment sounds quite expensive.

Another approach could be to use the depth buffer as a fake stencil
buffer. Since we don't usually use the depth buffer with Clutter you
could find a way to load your stencil mask into the depth buffer and
enable depth testing.

Another could be to hack Cogl/Clutter to force multi texturing of all
primitives that need to be stenciled and either use glAlphaFunc or some
texture combine function to discard fragments.

Basically if you don't have a reliable stencil buffer implementation
Clutter doesn't do much to help. There are a number of hacks that may
help but they need to be considered case by case because they tend so
sacrifice something else. Maintaining all these fallback possibilities
and determining which one to use and when would be very hard for us to
maintain in Clutter.

kind regards and good luck,
- Robert

-- 
Robert Bragg, Intel Open Source Technology Center

-- 
To unsubscribe send a mail to [email protected]

Reply via email to