ok, i'm attaching a new patch.
the patch basically checks to see if the current context is evas' gl context
and if it is, it'll call evas_gl_common_context_flush(). I think this
is the proper
way to go. :-)
cheers,
sung
On Mon, Apr 18, 2011 at 6:39 PM, Sung W. Park <sung...@gmail.com> wrote:
> 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
>>
>
>
Index: src/modules/engines/gl_x11/evas_engine.c
===================================================================
--- src/modules/engines/gl_x11/evas_engine.c (revision 58721)
+++ src/modules/engines/gl_x11/evas_engine.c (working copy)
@@ -2423,6 +2423,24 @@
sfc = (Render_Engine_GL_Surface*)surface;
ctx = (Render_Engine_GL_Context*)context;
+ if (re->win)
+ {
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ if ((eglGetCurrentContext() == re->win->egl_context[0]) ||
+ (eglGetCurrentSurface(EGL_READ) == re->win->egl_surface[0]) ||
+ (eglGetCurrentSurface(EGL_DRAW) == re->win->egl_surface[0]))
+ {
+ evas_gl_common_context_use(re->win->gl_context);
+ evas_gl_common_context_flush(re->win->gl_context);
+ }
+#else
+ if (glXGetCurrentContext() == re->win->context)
+ {
+ evas_gl_common_context_use(re->win->gl_context);
+ evas_gl_common_context_flush(re->win->gl_context);
+ }
+#endif
+ }
if ((!sfc) || (!ctx))
{
------------------------------------------------------------------------------
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
