well, you're actually right. I was a little concerned about that aspect but
now that you
point it out, it makes sense with multiple windows.
The real issue is that we have is evas_gl butting in and changing the
currrent context that evas isn't aware of. the proper way to resolve
this would be for evas_gl_make_current to do a
evass_gl_common_context_flush().
the fix was a little hacky i admit..
I'll go ahead and fix evas_gl and send another patch. =)
On Mon, Apr 18, 2011 at 3:50 PM, Carsten Haitzler <ras...@rasterman.com>wrote:
> On Wed, 13 Apr 2011 12:23:22 +0900 "Sung W. Park" <sung...@gmail.com>
> said:
>
> that patch seems wrong. if you are changing target window... and you have a
> previous window.. it flushes the gl render queue for the previous window
> target
> (or if the flush/use of the window) is flushed. you move the flush to AFTER
> setting the new context info (like new surfaces for read/write). that seems
> wrong.
>
> > Hi all,
> >
> > I've been toying around with creating a simple GLView smart object that
> > allows users do GL rendering simply. Eventually, I would like to see
> this
> > as an Elementary widget called GLView. The idea behind this is that
> > if evas_gl provides the low level stuff, GLView gives the simplified
> > user-version.
> > I'll start another email thread later on this topic.
> >
> > The reason why I'm mentioning the above is because while working on
> GLView,
> > I've noticed an interesting behavior. (You can see this by
> > compiling/running the
> > program that I'm attaching.) I'm drawing a simple blended Triangle in
> > the middle
> > of the GLView object and what i'm getting is a smaller inverted red
> triangle
> > on the top left corner of the GLView object. Obviously, something was
> messing
> > with the state of my GL code.
> >
> > I've tracked this issue down to eng_window_use() in evas_x_main.c under
> gl_x11
> > module. In the code,
> > _________________
> > void
> > eng_window_use(Evas_GL_X11_Window *gw)
> > {
> > if ((_evas_gl_x11_window != gw) || (force_use))
> > {
> > if (_evas_gl_x11_window)
> > {
> > evas_gl_common_context_use(_evas_gl_x11_window->gl_context);
> >
> evas_gl_common_context_flush(_evas_gl_x11_window->gl_context);
> > }
> > _evas_gl_x11_window = gw;
> > if (gw)
> > {
> > ....
> > // Make Current Stuff..
> > _________________
> >
> > I've noticed that evas_gl_common_context_flush() gets called before it
> does
> > MakeCurrent(). When the evas_gl_common_context_flush() gets called, it
> resets
> > some shader stuff and does GL calls that tell the context to use the
> > particular shaders. This explains why my GLView was picking on what
> seemed
> > to be the MVP matrix states that Evas was using.
> >
> > Instead, what I think should happen is that the flush should be called
> after
> > MakeCurrent happens. Otherwise, you're not guaranteeing that your GL
> calls
> > are being applied to the proper context. I've tried that and it seems to
> > address the
> > problem.
> >
> > You can try running the glview program that I'm attaching before you
> apply
> > the patch and also try running it after you apply the patch.
> >
> > Let me know if this seems reasonable or I'm missing something somewhere.
> >
> > Thanks!
> >
> > cheers,
> > Sung
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) ras...@rasterman.com
>
>
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
