from:"Sung W. Park"

Re: [E-devel] [e-users] EFL developers days

2016-05-11 Thread Sung W. Park

wine tasting activity sounds nice.. ;-)

On Thu, May 12, 2016 at 1:50 AM, Tom Hacohen  wrote:

> It's dark inside anyway, so you wouldn't know any better. It's not
> necessarily an evening thing.
>
> The problem is that climbing is something that you need to be strong for,
> or at least have the technique, and many people don't like it (I personally
> do). The other one, the museum, is not a very good social event because you
> need to be quiet and you wander off on your own.
>
> I know it's not your thing, but another idea that just came to mind that is
> more of a Parisian themed idea: wine tasting activity, or a cooking
> activity or something of that sort.
>
> My personal favourite is bowling, but I think almost any idea is better
> than the museum (which because of the above we'll end up doing).
>
>
> On Wed, May 11, 2016 at 5:43 PM, Cedric BAIL  wrote:
>
> > On Wed, May 11, 2016 at 2:46 AM, Tom Hacohen 
> wrote:
> > > On 11/05/16 10:45, Tom Hacohen wrote:
> > >> On 11/05/16 08:50, Stefan Schmidt wrote:
> > >>> On 05/05/16 01:55, Cedric BAIL wrote:
> >  I would like to remind everyone that EFL developers days will happen
> >  later this month in Paris. If you have made your decision, it would
> be
> >  good to update your vote
> >  (
> >
> https://phab.enlightenment.org/w/events/enlightenment_developer_days_2016/
> > ).
> > 
> >  Also as a big part of the event is to do hacking together, don't
> >  hesitate to bring your prefered device along !
> > 
> >  Also as Saturday afternoon, we will try to setup some social event
> and
> >  by just the actual number of expected people, it will be necessary
> to
> >  book whatever we finally plan to do. So here is a vote
> >  https://phab.enlightenment.org/V23 . If people have other idea than
> >  climbing or visiting the Musee des Arts et Metiers, please raise
> your
> >  hands now ! The vote will be closed in a week from now.
> > >>>
> > >>> So far we only have 5 votes but 22 registered attendees. :)
> > >>>
> > >>> As an additional note please let me know if you have any input for
> > >>> hacking sessions we have planned.
> > >>> I will put some slides together with topics people can work on during
> > >>> this sessions.
> > >>
> > >> Posting again with some more info + both ML this time. :)
> > >>
> > >> I'm sorry I'm only bringing it up now, but I didn't see the vote. The
> > >> subject "EFL developers day" with the generic reminder first paragraph
> > >> meant I didn't read the rest of the email and see this. Please when
> you
> > >> have a "call for action" mark the title as such, or at the very least,
> > >> have a non generic title. I'm only seeing this now because of Stefan's
> > >> email.
> > >>
> > >> In the last email we talked about ideas there were plenty more, like
> > >> paintball and kart racing. Why are they not in this vote?
> > >
> > > Or bowling.
> >
> > There isnt any painball or kart racing track that I know of inside
> > Paris or at a short distance. Bowling is another possibility, but
> > isn't it more something you do in the evening ?
> > --
> > Cedric BAIL
> >
> >
> >
> --
> > Mobile security can be enabling, not merely restricting. Employees who
> > bring their own devices (BYOD) to work are irked by the imposition of MDM
> > restrictions. Mobile Device Manager Plus allows you to control only the
> > apps on BYO-devices by containerizing them, leaving personal data
> > untouched!
> > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___

Re: [E-devel] Possible OpenGL ES 2.0 + Evas 3D Incompatibility Problem - only EVAS_3D_SHADE_MODE_DIFFUSE works

2014-11-12 Thread Sung W. Park

Hi Brian,

Unfortunately, Evas 3D hasn't been extensively tested on a lot of GPUs,
especially on the one that you're using.  From what I know about Mali
400mp, it's an older GPU with separate vertext/fragment processors.  By the
way, I'm not the one who developed the library so I don't know all the
details.  From what I know about GPUs and from what I recall, it was only
tested on a qualcomm mobile chipset.  The developement happened on a
desktop machine.

Looking at your description, it appears that Mali 400mp has a hard time
processing the shader code for other types of lighting mode, which would
inevitabily require more complex shader codes.  I guess one thing that you
need to find out is if Mali400mp supports the kind of shader code that's
there.  like the number of uniforms and the complexity of the code.  If it
doesn't support the code, then i guess you'd need to figure out if you can
do a workaround.  Unfortunately, both of these require good understanding
of shaders.

I'm CC'ing Taekyun, the guy who wrote most of it, so he can aslo respond.

Sorry for the late response.  I got completely swamped with work after the
weekend.

Hope you can get it sorted out.

cheers,
Sung




On Thu, Nov 13, 2014 at 12:29 PM, Brian Wang brian.wang.0...@gmail.com
wrote:

 Hello all,

 Symptoms:
 Running efl/src/examples/evas/evas-3d-xxx.c examples in efl-1.11 is
 generally unsuccessful on my target box (Allwinner A13 with Mali-400 MP
 GPU).  They often result in no rendering at all.
 Everything runs fine on my x86 box though (not OPENGL ES 2.0, I suppose)

 After some experiments, I have found that only EVAS_3D_SHADE_MODE_DIFFUSE
 works.  Other shade modes, like vertex color, phong, map, etc., simply
 result in no rendering at all.

 I have been littering glGetError/GLERR calls in evas_3d files but could not
 get any further.  There are no warnings or errors while running the
 non-rendering examples.  Changing the shade mode to DIFFUSE will make the
 objects, say cube, appear on the screen.

 I did find some discrepancies between EFL and OPENGL ES document though.
 1.  Default precision should be set in the shader code.  Some GPU
 implementations are pretty strict...
 2.  glTexImage2D usage may not be proper.  In
 evas_gl_3d.c:e3d_texture_data_set(), glTexImage2D is called with different
 internal format and format, while the the official doc states that the
 internal format must match format.  (Ref:
 https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml).

 What can I do to narrow down the problem?  _shader_compile does not issue
 any message.

 Any help is much appreciated.

 Thanks in advance.


 Brian

 --
 brian
 --

 iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.

 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Problem running evas_3d_cube example

2014-11-07 Thread Sung W. Park

I could be wrong but it seems like your gles compiler's complaining about
precision not being set in the shader.

Some GLES compilers will complain and others gracefully ignores it if one's
not found.

I don't have time to look at the code as I'll be away for the weekend but
you may look at the evas_3d  fragment shader code and see if there's
something like

  precision mediump float;\n  or
  precision highp float;\n

is in there somewhere

that would be my guess.

good luck.
Sung


On Fri, Nov 7, 2014 at 6:55 PM, Brian Wang brian.wang.0...@gmail.com
wrote:

 On Fri, Nov 7, 2014 at 5:49 PM, ChunEon Park her...@naver.com wrote:

  failed compile shader sources with your opengl driver.
 
  did u launch the elementary_test with gl ?
 
  $ELM_ENGINE=gl elementary_test
 

 Yes, elementary_test is run with ELM_ENGINE=gl.  The gears spin smoothly
 without problems.
 It is the evas_3d_cube and other evas 3D examples that are causing the
 problem.

 Is it a setup problem?

 Thank you.


 Brian


 
  
  -Regards, Hermet-
  -Original Message-
  From: Brian Wangbrian.wang.0...@gmail.com
  To: eenlightenment-devel@lists.sourceforge.net;
  Cc:
  Sent: 2014-11-07 (금) 17:36:37
  Subject: [E-devel] Problem running evas_3d_cube example
 
  Hello all,
 
  I tried to run evas_3d_cube example on my board.  Lots of error messages
  output like these:
  ---
  ERR498:evas_main
 modules/evas/engines/gl_common/evas_gl_3d_shader.c:1112
  _shader_compile() Shader compilation failed.
  0:1: S0032: no default precision defined for variable
  ERR498:evas_main
 modules/evas/engines/gl_common/evas_gl_3d_shader.c:1140
  _program_build() Failed to compile fragment shader.
  ERR498:evas-gl_common
  modules/evas/engines/gl_common/evas_gl_3d_renderer.c:229
  e3d_renderer_draw() Failed to create shader program.
  ---
 
  EFL version is 1.11.  I had the gears test of elementary_test running ok.
  I have no clue if this is my environment setup or a problem with EFL.
 
  Any hints will be appreciated.
 
  Thanks in advance.
 
 
  Brian
 
 
  --
  brian
  --
 
  iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
 
 
 --
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
 
 --
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 



 --
 brian
 --

 iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

 --
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] wayland.. egl.. barf!

2014-08-18 Thread Sung W. Park

are you sure Cedric was a sounding board? or was he the one who created the
bug in the first place and then pretended like he gave you excellent
feedback? =P


On Tue, Aug 19, 2014 at 5:19 AM, Chris Michael devilho...@comcast.net
wrote:

 On 08/18/2014 04:16 PM, Chris Michael wrote:
  On 08/18/2014 02:01 AM, Carsten Haitzler (The Rasterman) wrote:
  elm engine is wayland_egl:
 
  http://www.enlightenment.org/ss/e-53f19667607690.40512419.png
 
  need i say more.
 
  WAT?
 
 
  Fixed now ! :)
 
  Thanks Cedric for being a sounding board !! ;)
 
  Cheers,
  dh

 Well, sort of fixed. It's no longer a black rectangle :D ... but there
 are some issues when manually resizing. I'll poke some more tomorrow on it.

 Cheers,
 dh




 --
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] evas_3d_utils.h should be public.

2014-05-26 Thread Sung W. Park

From what I recall, the reason why the util functions was to keep the
evas_3d a high level library.  and so we put a lot of time into designing
the apis.   that's the reason why it was hidden initially. if you guys
think it's good to expose the math functions, i guess it'd be fine.

-Sung


On Tue, May 27, 2014 at 11:21 AM, ChunEon Park her...@naver.com wrote:

 There would be bunch of 2d/3d math types/functions(for matrixs, vectors,
 planes, quarternions...)  required once evas afford 3d stuffs.
 This kind of functions will be very commonly useful for 2d/3d graphics
 computation in efl/app.

 
 -Regards, Hermet-

 -Original Message-
 From: Cedric BAILcedric.b...@free.fr
 To: Enlightenment developer list
 enlightenment-devel@lists.sourceforge.net;
 Cc:
 Sent: 2014-05-26 (월) 22:31:27
 Subject: Re: [E-devel] evas_3d_utils.h should be public.

 On Mon, May 26, 2014 at 7:13 AM, David Seikel onefang@gmail.com wrote:
  On Mon, 26 May 2014 13:44:49 +0900 (KST) ChunEon Park
  hermet@naver.com wrote:
  Agree your opinion.
  and let them in Eina Math?
 
  I don't see anything called Eina math, but that sounds like a logical
  place, even if we have to create it.

 Would make sense to me to.
 --
 Cedric BAIL


 --
 The best possible search technologies are now affordable for all companies.
 Download your FREE open source Enterprise Search Engine today!
 Our experts will assist you in its installation for $59/mo, no commitment.
 Test it for FREE on our Cloud platform anytime!

 http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


 --
 The best possible search technologies are now affordable for all companies.
 Download your FREE open source Enterprise Search Engine today!
 Our experts will assist you in its installation for $59/mo, no commitment.
 Test it for FREE on our Cloud platform anytime!

 http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/elementary] master 01/01: ELM_GLView: added glview_manygears example to elementary_test

2014-03-25 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=8e2d312aeb28e8cf64f47eafda425e3566cef290

commit 8e2d312aeb28e8cf64f47eafda425e3566cef290
Author: Sung W. Park sung...@gmail.com
Date:   Wed Mar 26 00:26:46 2014 +0900

ELM_GLView: added glview_manygears example to elementary_test

Added a more complex glview example to the elementary test.

- the gears lighting matches the original glx gears example.
- Added a background image to show that Glview works well with existing
  ELM winsets.
- Added 5 gears and buttons to increase/decrease gear teeth
---
 src/bin/Makefile.am |   1 +
 src/bin/test.c  |   6 +-
 src/bin/test_glview_manygears.c | 951 
 3 files changed, 956 insertions(+), 2 deletions(-)

diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index 3ebd91f..98b20fc 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -82,6 +82,7 @@ test_gesture_layer2.c \
 test_gesture_layer3.c \
 test_glview_simple.c \
 test_glview.c \
+test_glview_manygears.c \
 test_grid.c \
 test_hover.c \
 test_hoversel.c \
diff --git a/src/bin/test.c b/src/bin/test.c
index 1dd840c..268f739 100644
--- a/src/bin/test.c
+++ b/src/bin/test.c
@@ -211,6 +211,7 @@ void test_win_wm_rotation(void *data, Evas_Object *obj, 
void *event_info);
 void test_grid(void *data, Evas_Object *obj, void *event_info);
 void test_glview_simple(void *data, Evas_Object *obj, void *event_info);
 void test_glview(void *data, Evas_Object *obj, void *event_info);
+void test_glview_manygears(void *data, Evas_Object *obj, void *event_info);
 void test_3d(void *data, Evas_Object *obj, void *event_info);
 void test_naviframe(void *data, Evas_Object *obj, void *event_info);
 void test_naviframe2(void *data, Evas_Object *obj, void *event_info);
@@ -671,9 +672,10 @@ add_tests:
ADD_TEST(NULL, General, Scaling 2, test_scaling2);
 
//--//
-   ADD_TEST(NULL, 3D, GLViewSimple, test_glview_simple);
-   ADD_TEST(NULL, 3D, GLView, test_glview);
ADD_TEST(NULL, 3D, Evas Map 3D, test_3d);
+   ADD_TEST(NULL, 3D, GLViewSimple, test_glview_simple);
+   ADD_TEST(NULL, 3D, GLView Gears, test_glview);
+   ADD_TEST(NULL, 3D, GLView Many Gears, test_glview_manygears);
 
//--//
 #ifdef HAVE_ELEMENTARY_WEB
diff --git a/src/bin/test_glview_manygears.c b/src/bin/test_glview_manygears.c
new file mode 100644
index 000..34627a5
--- /dev/null
+++ b/src/bin/test_glview_manygears.c
@@ -0,0 +1,951 @@
+/*
+ * Copyright (C) 1999-2001  Brian Paul   All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Ported to GLES2.
+ * Kristian Høgsberg k...@bitplanet.net
+ * May 3, 2010
+ *
+ * Improve GLES2 port:
+ *   * Refactor gear drawing.
+ *   * Use correct normals for surfaces.
+ *   * Improve shader.
+ *   * Use perspective projection transformation.
+ *   * Add FPS count.
+ *   * Add comments.
+ * Alexandros Frantzis alexandros.frant...@linaro.org
+ * Jul 13, 2010
+ *
+ * Ported to Elm_GLView and added features for testing purposes:
+ ** Has 5 gears
+ ** Number of teeth can be increased to test under many vertices
+ ** Up/Down button increases the teeth number
+ * Sung W. Park sung...@gmail.com
+ * (Some positioning and numbers taken from KHCho's example)
+ * Oct 27, 2011
+ *
+ */
+#ifdef HAVE_CONFIG_H
+# include elementary_config.h
+#endif
+#include Elementary.h
+
+#ifndef M_PI
+#define M_PI 3.14159265
+#endif
+
+#define STRIPS_PER_TOOTH 7
+#define VERTICES_PER_TOOTH 34
+#define GEAR_VERTEX_STRIDE 6
+
+/* A set of macros for making the creation of the gears easier */
+#define  GEAR_POINT(r, da) { (r) * c[(da)], (r) * s[(da)] }
+#define  SET_NORMAL(x, y, z) do { \
+ normal[0] = (x); normal[1] = (y); normal[2] = (z); \
+} while(0);
+
+#define  GEAR_VERT(v, point, sign) vert((v), p[(point)].x, p[(point)].y

[EGIT] [core/elementary] master 01/01: elementary_test glview: fixed segv on close

2014-02-21 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/elementary.git/commit/?id=5c65df8c7f4ddae5f916fa48e6063c7f2133cb58

commit 5c65df8c7f4ddae5f916fa48e6063c7f2133cb58
Author: Sung W. Park sung...@gmail.com
Date:   Sat Feb 22 03:15:57 2014 +0900

elementary_test glview: fixed segv on close

It was deleting gldata object twice upon closing the program.
---
 src/bin/test_glview.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/bin/test_glview.c b/src/bin/test_glview.c
index 463761c..c840b97 100644
--- a/src/bin/test_glview.c
+++ b/src/bin/test_glview.c
@@ -516,9 +516,7 @@ static void
 _del(void *data EINA_UNUSED, Evas *evas EINA_UNUSED, Evas_Object *obj, void 
*event_info EINA_UNUSED)
 {
Ecore_Animator *ani = evas_object_data_get(obj, ani);
-   GLData *gld = evas_object_data_get(obj, gld);
ecore_animator_del(ani);
-   free(gld);
 }
 
 static void

--

[EGIT] [core/efl] master 01/01: evas gl: added partial rendering support for qcom extension

2014-02-14 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=2b4a7b438def96d01a5c0bb85d2c9636773d333d

commit 2b4a7b438def96d01a5c0bb85d2c9636773d333d
Author: Sung W. Park sung...@gmail.com
Date:   Sat Feb 15 02:33:47 2014 +0900

evas gl: added partial rendering support for qcom extension

When running in direct rendering mode, properly support partial
rendering if the extension is properly supported.

Also, fixed the SwapBufferwWithDamage rectangle coordinate bug.
It wasn't properly y-inverted before.
---
 src/modules/evas/engines/gl_common/evas_gl_api.c   |  28 -
 .../evas/engines/gl_common/evas_gl_common.h|   9 +-
 .../evas/engines/gl_common/evas_gl_context.c   |  58 +++--
 src/modules/evas/engines/gl_common/evas_gl_core.c  | 132 +++--
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  13 +-
 .../evas/engines/gl_common/evas_gl_core_private.h  |  10 +-
 src/modules/evas/engines/gl_x11/evas_engine.c  |  86 ++
 src/modules/evas/engines/wayland_egl/evas_engine.c |  14 ++-
 8 files changed, 298 insertions(+), 52 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_api.c 
b/src/modules/evas/engines/gl_common/evas_gl_api.c
index d831f9d..0555b4a 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api.c
@@ -56,7 +56,9 @@ void
 _evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
 {
EVGL_Context *ctx = NULL;
+   EVGL_Resource *rsc;
 
+   rsc = _evgl_tls_resource_get();
ctx = _evgl_current_context_get();
 
if (!ctx)
@@ -69,13 +71,35 @@ _evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
if (framebuffer==0)
  {
 if (_evgl_direct_enabled())
-   glBindFramebuffer(target, 0);
+  {
+ glBindFramebuffer(target, 0);
+
+ if (rsc-direct.partial.enabled)
+   {
+  if (!ctx-partial_render)
+{
+   evgl_direct_partial_render_start();
+   ctx-partial_render = 1;
+}
+   }
+  }
 else
-   glBindFramebuffer(target, ctx-surface_fbo);
+  {
+ glBindFramebuffer(target, ctx-surface_fbo);
+  }
 ctx-current_fbo = 0;
  }
else
  {
+if (_evgl_direct_enabled())
+  {
+ if (ctx-current_fbo == 0)
+   {
+  if (rsc-direct.partial.enabled)
+ evgl_direct_partial_render_end();
+   }
+  }
+
 glBindFramebuffer(target, framebuffer);
 
 // Save this for restore when doing make current
diff --git a/src/modules/evas/engines/gl_common/evas_gl_common.h 
b/src/modules/evas/engines/gl_common/evas_gl_common.h
index 9e1579a..a6b624d 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_common.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_common.h
@@ -531,6 +531,8 @@ struct _Evas_Engine_GL_Context
void *egldisp;
void *eglctxt;
 #endif
+
+   GLuint preserve_bit;
 };
 
 struct _Evas_GL_Texture_Pool
@@ -692,7 +694,12 @@ void  
evas_gl_common_context_free(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_use(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_newframe(Evas_Engine_GL_Context *gc);
 void  evas_gl_common_context_resize(Evas_Engine_GL_Context *gc, 
int w, int h, int rot);
+void  evas_gl_common_tiling_start(Evas_Engine_GL_Context *gc,
+  int rot, int gw, int gh,
+  int cx, int cy, int cw, int ch,
+  int bitmask);
 void  evas_gl_common_context_done(Evas_Engine_GL_Context *gc);
+void  evas_gl_common_tiling_done(Evas_Engine_GL_Context *gc);
 void  
evas_gl_common_context_target_surface_set(Evas_Engine_GL_Context *gc, 
Evas_GL_Image *surface);
 
 void  evas_gl_common_context_line_push(Evas_Engine_GL_Context *gc,
@@ -818,7 +825,7 @@ void  
evas_gl_common_poly_draw(Evas_Engine_GL_Context *gc, Evas_GL_P
 
 void  evas_gl_common_line_draw(Evas_Engine_GL_Context *gc, int x1, 
int y1, int x2, int y2);
 
-int   evas_gl_common_buffer_dump(Evas_Engine_GL_Context *gc, const 
char* dname, const char* fname, int frame);
+int   evas_gl_common_buffer_dump(Evas_Engine_GL_Context *gc, const 
char* dname, const char* fname, int frame, const char* suffix);
 
 extern void   (*glsym_glGenFramebuffers)  (GLsizei a, GLuint *b);
 extern void   (*glsym_glBindFramebuffer)  (GLenum a, GLuint b);
diff --git a/src/modules/evas/engines/gl_common/evas_gl_context.c 
b/src/modules/evas/engines/gl_common/evas_gl_context.c
index 5626ce4..2e447d9 100644
--- a/src/modules/evas/engines/gl_common

[EGIT] [core/efl] master 01/01: evas_gl : Fixed macro substitution bug in evas_gl

2013-11-12 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=90bbc21d02b9cdc7e074884812950d27e015c2ac

commit 90bbc21d02b9cdc7e074884812950d27e015c2ac
Author: Sung W. Park dunamis.p...@samsung.com
Date:   Wed Nov 13 15:39:12 2013 +0900

evas_gl : Fixed macro substitution bug in evas_gl

In evas_gl_api_ext_def.h there're calls such as:

_EVASGL_EXT_DRVNAME(EGL_KHR_image_base)

The macro is defined in evas_gl_api_ext.c as:

(strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)

if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;

But EGL_KHR_image_base is itself a macro, which is defined
in EGL/eglext.h like this:

Thus, the _EVASGL_EXT_CHECK_SUPPORT macro will unwrap into:

(strstr(glexts, 1) != NULL || strstr(glueexts, 1) != NULL)

instead of intended:

(strstr(glexts, EGL_KHR_image_base) != NULL ||
 strstr(glueexts, EGL_KHR_image_base) != NULL)

This patch fixes this by applying stringification earlier in
_EVASGL_EXT_DRVNAME

Bugfix reported by jinhyung...@samsung.com
---
 src/modules/evas/engines/gl_common/evas_gl_api_ext.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_api_ext.c 
b/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
index dcf5f1c..0573c6d 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api_ext.c
@@ -184,13 +184,13 @@ re-info-info.screen);
  }
 
 #define _EVASGL_EXT_CHECK_SUPPORT(name) \
-   (strstr(glexts, #name) != NULL || strstr(glueexts, #name) != NULL)
+   (strstr(glexts, name) != NULL || strstr(glueexts, name) != NULL)
 
 #define _EVASGL_EXT_DISCARD_SUPPORT() \
*ext_support = 0;
 
 #define _EVASGL_EXT_DRVNAME(name) \
-   if (_EVASGL_EXT_CHECK_SUPPORT(name)) *ext_support = 1;
+   if (_EVASGL_EXT_CHECK_SUPPORT(#name)) *ext_support = 1;
 
 #define _EVASGL_EXT_FUNCTION_BEGIN(ret, name, param) \
  { \

--

[EGIT] [core/efl] master 01/01: EvasGL: cleaning up unnecessary code.

2013-10-29 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9bb4c4869199118d9d16c87edc5084e8d1d49fb7

commit 9bb4c4869199118d9d16c87edc5084e8d1d49fb7
Author: Sung W. Park dunamis.p...@samsung.com
Date:   Wed Oct 30 10:47:52 2013 +0900

EvasGL: cleaning up unnecessary code.

Cleaning up unnecessary code.
---
 src/modules/evas/engines/gl_common/evas_gl_core.c  | 50 --
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  7 ---
 .../evas/engines/gl_common/evas_gl_core_private.h  |  1 -
 3 files changed, 58 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c 
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index a065bd4..e5009cd 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -1869,38 +1869,6 @@ evgl_direct_info_clear()
rsc-direct.enabled = EINA_FALSE;
 }
 
-/*
-void
-evgl_direct_img_obj_set(Evas_Object *img, int rot)
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return;
-
-   // Normally direct rendering isn't allowed if alpha is on and
-   // rotation is not 0.  BUT, if override is on, allow it.
-   if (rot!=0)
- {
-if (evgl_engine-direct_override)
-   rsc-direct.img = img;
-else
-   rsc-direct.img = NULL;
- }
-   else
-  rsc-direct.img = img;
-}
-
-Evas_Object *
-evgl_direct_img_obj_get()
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return NULL;
-
-   return rsc-direct.img;
-}
-*/
-
 Evas_GL_API *
 evgl_api_get()
 {
@@ -1909,24 +1877,6 @@ evgl_api_get()
return gl_funcs;
 }
 
-
-/*
-void
-evgl_direct_img_clip_set(int c, int x, int y, int w, int h)
-{
-   EVGL_Resource *rsc;
-
-   if (!(rsc=_evgl_tls_resource_get())) return;
-
-   rsc-master_clip = c;
-   rsc-clip[0] = x;
-   rsc-clip[1] = y;
-   rsc-clip[2] = w;
-   rsc-clip[3] = h;
-
-}
-*/
-
 void
 evgl_direct_override_get(int *override, int *force_off)
 {
diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.h 
b/src/modules/evas/engines/gl_common/evas_gl_core.h
index bbd5b24..587e8b0 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.h
@@ -33,16 +33,9 @@ int  evgl_native_surface_get(EVGL_Surface *sfc, 
Evas_Native_Surface *ns)
 Evas_GL_API *evgl_api_get();
 int  evgl_direct_rendered();
 
-
-/*
-extern void evgl_direct_img_obj_set(Evas_Object *img, int rot);
-extern Evas_Object *evgl_direct_img_obj_get();
-*/
-
 void evgl_direct_info_set(int win_w, int win_h, int rot, int img_x, 
int img_y, int img_w, int img_h, int clip_x, int clip_y, int clip_w, int 
clip_h);
 void evgl_direct_info_clear();
 
-//extern void evgl_direct_img_clip_set(int c, int x, int y, int w, int 
h);
 void evgl_direct_override_get(int *override, int *force_off);
 
 #endif //_EVAS_GL_CORE_H
diff --git a/src/modules/evas/engines/gl_common/evas_gl_core_private.h 
b/src/modules/evas/engines/gl_common/evas_gl_core_private.h
index 37e8cc5..254da65 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core_private.h
+++ b/src/modules/evas/engines/gl_common/evas_gl_core_private.h
@@ -212,7 +212,6 @@ struct _EVGL_Resource
struct {
 EVGLNative_Surface   surface;
 int  rendered;
-//Evas_Object *img;
 
 int  rot;
 int  win_w;

--

[EGIT] [core/efl] master 01/01: EvasGL: Fixed direct rendering not clipping issue

2013-10-24 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=7dc102c55f6de2a9952cf79ffa69b50ab66df4c1

commit 7dc102c55f6de2a9952cf79ffa69b50ab66df4c1
Author: Sung W. Park dunamis.p...@samsung.com
Date:   Thu Oct 24 17:37:22 2013 +0900

EvasGL: Fixed direct rendering not clipping issue

Evas GL direct rendering mode didn't properly take into account
the image object's clipping information and clip the region that
it was directly rendering to. Hence there were issues with the
direct rendering region drawing over the objects that are sitting
on top of it.

Also, cleaned up the direct rendering coordinate computation code
and a nasty dependency with image object that should have been
removed a long time ago.  Basically the evas-gl engine was directly
accessing the image object data structure for its data when it
really should have just passed along necessary information.
---
 ChangeLog  |   3 +
 src/modules/evas/engines/gl_common/evas_gl_api.c   | 231 +
 src/modules/evas/engines/gl_common/evas_gl_core.c  |  76 +--
 src/modules/evas/engines/gl_common/evas_gl_core.h  |  39 ++--
 .../evas/engines/gl_common/evas_gl_core_private.h  |  25 ++-
 src/modules/evas/engines/gl_x11/evas_engine.c  |  33 ++-
 src/modules/evas/engines/wayland_egl/evas_engine.c |  21 +-
 7 files changed, 237 insertions(+), 191 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d952a22..c5042ad 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,6 @@
+2013-10-24  Sung W. Park (sung_)
+* EvasGL: Fixed direct rendering mode not clipping to its clip region.
+
 2013-10-18  Youngbok Shin
 
 * Fixed the textblock format to be drawn according to
diff --git a/src/modules/evas/engines/gl_common/evas_gl_api.c 
b/src/modules/evas/engines/gl_common/evas_gl_api.c
index 968f7e1..6b93548 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_api.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_api.c
@@ -20,7 +20,7 @@ void _make_current_check(const char* api)
 
if (!ctx)
  {
-CRIT(\e[1;33m%s\e[m: Current Context NOT SET: GL Call Should NOT Be 
Called without MakeCurrent!!!, api); 
+CRIT(\e[1;33m%s\e[m: Current Context NOT SET: GL Call Should NOT Be 
Called without MakeCurrent!!!, api);
  }
 }
 
@@ -157,45 +157,23 @@ _evgl_glReleaseShaderCompiler(void)
 // returns: objc[4] (nc[4]) tranformed  (x, y, width, heigth) in gl coord
 // returns: cc[4] cliped coordinate in original coordinate
 static void
-compute_gl_coordinates(Evas_Object *obj, int rot, int clip_image,
+compute_gl_coordinates(int win_w, int win_h, int rot, int clip_image,
int x, int y, int width, int height,
-   int clip[4],
+   int img_x, int img_y, int img_w, int img_h,
+   int clip_x, int clip_y, int clip_w, int clip_h,
int imgc[4], int objc[4], int cc[4])
 {
-   Evas_Object_Protected_Data *pd = eo_data_scope_get(obj, EVAS_OBJ_CLASS);
-
-   int obj_x, obj_y, obj_w, obj_h;
-   int clip_x, clip_y, clip_w, clip_h;
-   int out_w, out_h;
-
-   // Original Coordinates
-   obj_x = pd-cur-geometry.x;
-   obj_y = pd-cur-geometry.y;
-   obj_w = pd-cur-geometry.w;
-   obj_h = pd-cur-geometry.h;
-
-   // Clip Region
-   clip_x = clip[0];
-   clip_y = clip[1];
-   clip_w = clip[2];
-   clip_h = clip[3];
-
-   // Output Window Size
-   out_w = pd-layer-evas-output.w;
-   out_h = pd-layer-evas-output.h;
-
-
if (rot == 0)
  {
 // oringinal image object coordinate in gl coordinate
-imgc[0] = obj_x;
-imgc[1] = out_h - obj_y - obj_h;
-imgc[2] = imgc[0] + obj_w;
-imgc[3] = imgc[1] + obj_h;
+imgc[0] = img_x;
+imgc[1] = win_h - img_y - img_h;
+imgc[2] = imgc[0] + img_w;
+imgc[3] = imgc[1] + img_h;
 
 // clip coordinates in gl coordinate
 cc[0] = clip_x;
-cc[1] = out_h - clip_y - clip_h;
+cc[1] = win_h - clip_y - clip_h;
 cc[2] = cc[0] + clip_w;
 cc[3] = cc[1] + clip_h;
 
@@ -208,20 +186,20 @@ compute_gl_coordinates(Evas_Object *obj, int rot, int 
clip_image,
else if (rot == 180)
  {
 // oringinal image object coordinate in gl coordinate
-imgc[0] = out_w - obj_x - obj_w;
-imgc[1] = obj_y;
-imgc[2] = imgc[0] + obj_w;
-imgc[3] = imgc[1] + obj_h;
+imgc[0] = win_w - img_x - img_w;
+imgc[1] = img_y;
+imgc[2] = imgc[0] + img_w;
+imgc[3] = imgc[1] + img_h;
 
 // clip coordinates in gl coordinate
-cc[0] = out_w - clip_x - clip_w;
+cc[0] = win_w - clip_x - clip_w;
 cc[1] = clip_y;
 cc[2] = cc[0] + clip_w;
 cc[3] = cc[1] + clip_h;
 
 // transformed (x,y,width,height) in gl coordinate
-objc[0] = imgc[0] + obj_w - x - width;
-objc[1] = imgc[1] + obj_h

[EGIT] [core/efl] master 01/01: Evas: EGL-GL backends. Call eglReleaseThread() upon shutdown

2013-10-13 Thread Sung W . Park

sung pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=56e71e05bb39b90f71f5bfdedcc8211c542ee176

commit 56e71e05bb39b90f71f5bfdedcc8211c542ee176
Author: Sung W. Park dunamis.p...@samsung.com
Date:   Mon Oct 14 14:33:25 2013 +0900

Evas: EGL-GL backends. Call eglReleaseThread() upon shutdown

Call proper cleanup code upon terminating egl use.
---
 src/modules/evas/engines/gl_x11/evas_x_main.c   | 1 +
 src/modules/evas/engines/wayland_egl/evas_wl_main.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/modules/evas/engines/gl_x11/evas_x_main.c 
b/src/modules/evas/engines/gl_x11/evas_x_main.c
index 1b78d4c..1a088ab 100644
--- a/src/modules/evas/engines/gl_x11/evas_x_main.c
+++ b/src/modules/evas/engines/gl_x11/evas_x_main.c
@@ -437,6 +437,7 @@ eng_window_free(Evas_GL_X11_Window *gw)
  {
 if (context) eglDestroyContext(gw-egl_disp, context);
 eglTerminate(gw-egl_disp);
+eglReleaseThread();
 context = EGL_NO_CONTEXT;
  }
 #else
diff --git a/src/modules/evas/engines/wayland_egl/evas_wl_main.c 
b/src/modules/evas/engines/wayland_egl/evas_wl_main.c
index 7efbb41..4c49570 100644
--- a/src/modules/evas/engines/wayland_egl/evas_wl_main.c
+++ b/src/modules/evas/engines/wayland_egl/evas_wl_main.c
@@ -212,6 +212,7 @@ eng_window_free(Evas_GL_Wl_Window *gw)
  {
 if (context) eglDestroyContext(gw-egl_disp, context);
 eglTerminate(gw-egl_disp);
+eglReleaseThread();
 context = EGL_NO_CONTEXT;
  }
 

--

[EGIT] [core/efl] master 01/01: EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.

2013-09-17 Thread Sung W . Park - Enlightenment Git

sung pushed a commit to branch master.

commit b9e3e6be57e178ce83433447bbaf79fbbda0f653
Author: Sung W. Park dunamis.p...@samsung.com
Date:   Tue Sep 17 17:22:26 2013 +0900

EvasGL: Fixed a bug where the wrong data variable to buffer alloc func.

It's an optional feature so it's not automatically turned on but
would have caused a segfault somewhere.  Somehow slipped notice
but fixed now.
---
 src/modules/evas/engines/gl_common/evas_gl_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/modules/evas/engines/gl_common/evas_gl_core.c 
b/src/modules/evas/engines/gl_common/evas_gl_core.c
index 5ae7a9e..c711a26 100644
--- a/src/modules/evas/engines/gl_common/evas_gl_core.c
+++ b/src/modules/evas/engines/gl_common/evas_gl_core.c
@@ -1695,7 +1695,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
  // Destroy created resources
  if (sfc-buffers_allocated)
{
-  if (!_surface_buffers_allocate(evgl_engine, sfc, 0, 0, 1))
+  if (!_surface_buffers_allocate(eng_data, sfc, 0, 0, 1))
 {
ERR(Unable to destroy surface buffers!);
return 0;
@@ -1708,7 +1708,7 @@ evgl_make_current(void *eng_data, EVGL_Surface *sfc, 
EVGL_Context *ctx)
  // Create internal buffers if not yet created
  if (!sfc-buffers_allocated)
{
-  if (!_surface_buffers_allocate(evgl_engine, sfc, sfc-w, 
sfc-h, 1))
+  if (!_surface_buffers_allocate(eng_data, sfc, sfc-w, 
sfc-h, 1))
 {
ERR(Unable Create Specificed Surfaces.  Unsupported 
format!);
return 0;

--

Re: [E-devel] Building efl on Mac OSX

2013-09-15 Thread Sung W. Park

Great! :)

-Sung


On Sun, Sep 15, 2013 at 5:00 AM, Leif Middelschulte 
leif.middelschu...@gmail.com wrote:

 Am Samstag, 14. September 2013 um 18:05 schrieb Stefan Schmidt:
  Hello.
 
  On Sat, 2013-09-14 at 17:21, Leif Middelschulte wrote:
   Am Samstag, 14. September 2013 um 17:16 schrieb Sung W. Park:
Hi all,
   
Has any of you tried compiling efl on Mac lately?
   
I've followed the Wiki page instructions before efl was merged
to a single tree and got it to work but now I've just tried it
again last night and I'm getting the following errors.
   
CC lib/ecore/lib_ecore_libecore_la-ecore_coroutine.lo
lib/ecore/ecore_coroutine.c: In function
'_ecore_coroutine_setjmp': lib/ecore/ecore_coroutine.c:124:
error: request for member 'env' in something not a structure or
union lib/ecore/ecore_coroutine.c:125: error: request for member
'env' in something not a structure or union
lib/ecore/ecore_coroutine.c: In function
'ecore_coroutine_resume': lib/ecore/ecore_coroutine.c:282:
error: incompatible types in assignment
lib/ecore/ecore_coroutine.c:289: error: too few arguments to
function 'longjmp' lib/ecore/ecore_coroutine.c:293: error:
incompatible types in assignment
lib/ecore/ecore_coroutine.c:295: error: incompatible types in
assignment lib/ecore/ecore_coroutine.c: In function
'ecore_coroutine_yield': lib/ecore/ecore_coroutine.c:310: error:
too few arguments to function 'longjmp'
   
Obviously this is all Cedric's doing as all bugs and errors come
from him ;-) but I was just wondering if any of you guys tried
it on Mac lately.
   
  
  
   Hey,
  
   actually, I'm waiting for the 1.8 release of efl to provide
   recipes for the Mac OS packager manager Homebrew. So I'm not
   bothering until the release happens.
  
 
 
  Which means it might, or in this case will, be broken for the
  release and only discovered afterwards. Everyone who cares about a
  specific distributions, architecture or setup should test _before_ a
  release so this can be fixed and working once the release is due.
 
 

 Sure,

 if the release of 1.8 is at least in sight, I might give it (packaging)
 another shot ;-)

 regards,

 Leif
 
  regards
  Stefan Schmidt
 
 
 --
  LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
  1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
  2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
  Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net (mailto:
 enlightenment-devel@lists.sourceforge.net)
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 



 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
 includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Building efl on Mac OSX

2013-09-14 Thread Sung W. Park

Hi all,

Has any of you tried compiling efl on Mac lately?

I've followed the Wiki page instructions before efl was merged to a single
tree and got it to work but now I've just tried it again last night and I'm
getting the following errors.

  CC   lib/ecore/lib_ecore_libecore_la-ecore_coroutine.lo
lib/ecore/ecore_coroutine.c: In function '_ecore_coroutine_setjmp':
lib/ecore/ecore_coroutine.c:124: error: request for member 'env' in
something not a structure or union
lib/ecore/ecore_coroutine.c:125: error: request for member 'env' in
something not a structure or union
lib/ecore/ecore_coroutine.c: In function 'ecore_coroutine_resume':
lib/ecore/ecore_coroutine.c:282: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c:289: error: too few arguments to function
'longjmp'
lib/ecore/ecore_coroutine.c:293: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c:295: error: incompatible types in assignment
lib/ecore/ecore_coroutine.c: In function 'ecore_coroutine_yield':
lib/ecore/ecore_coroutine.c:310: error: too few arguments to function
'longjmp'

Obviously this is all Cedric's doing as all bugs and errors come from him
;-) but I was just wondering if any of you guys tried it on Mac lately.

cheers,
Sung
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] could somebody design Enventor logo?

2013-09-03 Thread Sung W. Park

actually the Cat's ass version is quite intriguing.  It could be an easter
egg..  =)


On Sun, Sep 1, 2013 at 11:10 AM, Murilo Belluzzo
murilo.bellu...@gmail.comwrote:

 Any chance to have --enable-debug using the cat ass icon version?


 On Fri, Aug 30, 2013 at 11:01 AM, Gustavo Lima Chaves
 gl...@profusion.mobiwrote:

  * Raoul Hecky raoul.he...@gmail.com [2013-08-30 12:06:53 +0200]:
 
   Happy? :)
   [image: Images intégrées 1]
 
  One word -- respect.
 
  
   --
   Raoul Hecky
  
  
   2013/8/30 Carsten Haitzler ras...@rasterman.com
  
On Fri, 30 Aug 2013 09:58:15 +0200 Raoul Hecky 
 raoul.he...@gmail.com
said:
   
i have improved the icon.
   
 Hi!

 I was bored this morning so I did one quickly... Is something like
  that
 good for you?
 ;)

 [image: Images intégrées 1]

 --
 Raoul Hecky


 2013/8/30 Carsten Haitzler ras...@rasterman.com

  On Fri, 30 Aug 2013 15:12:16 +0900 (KST) ChunEon Park 
her...@naver.com
  said:
 
  https://i.chzbgr.com/maxW500/4528375296/h81227BB3/
 
   Could somebody design Enventor logo gladly?
  
   I'm not a professional for design as well as im  poor at deisn
  tool.
 :-3
  
   I hope you help me If you have talent for design.
  
   
   -Regards, Hermet-
  
 
   
 
 --
   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL
 2012,
more!
   Discover the easy way to master current and previous Microsoft
  technologies
   and advance your career. Get an incredible 1,500+ hours of
step-by-step
   tutorial videos with LearnDevNow. Subscribe today and save!
  
 
   
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
  
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 
  --
  - Codito, ergo sum - I code, therefore I am
--
  The Rasterman (Carsten Haitzler)ras...@rasterman.com
 
 
 
 
   
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012,
  more!
  Discover the easy way to master current and previous Microsoft
technologies
  and advance your career. Get an incredible 1,500+ hours of
  step-by-step
  tutorial videos with LearnDevNow. Subscribe today and save!
 
   
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
   
   
--
- Codito, ergo sum - I code, therefore I am
  --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
   
   
 
 
 
  
 
 --
   Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
   Discover the easy way to master current and previous Microsoft
  technologies
   and advance your career. Get an incredible 1,500+ hours of step-by-step
   tutorial videos with LearnDevNow. Subscribe today and save!
  
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
 
  --
  Gustavo Lima Chaves
  Senior Developer @ Intel - Open Source Technology Center
 
 
 
 --
  Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
  Discover the easy way to master current and previous Microsoft
 technologies
  and advance your career. Get an incredible 1,500+ hours of step-by-step
  tutorial videos with LearnDevNow. Subscribe today and save!
 
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!

Re: [E-devel] [EGIT] [core/efl] master 02/02: Evas: adding image dump debug feature for wayland_egl backend

2013-07-23 Thread Sung W. Park

No problem. :)

I was worried that I would break something since I couldn't compile it but
it was simple a simple addition so I just went ahead with it.

For big ones, I'll let you know. :)

cheers,
Sung


On Tue, Jul 23, 2013 at 2:58 PM, Christopher Michael cp.mich...@samsung.com
 wrote:

 Thank you for porting this !! :)

 Cheers,
 dh

 On 23/07/13 02:29, Sung W. Park - Enlightenment Git wrote:
  sung pushed a commit to branch master.
 
  commit 7aa516c01a620da3438de864ac0c0e5b80c93d0b
  Author: Sung W. Park dunamis.p...@samsung.com
  Date:   Tue Jul 23 10:23:36 2013 +0900
 
   Evas: adding image dump debug feature for wayland_egl backend
 
   Porting commit f10c108283d9b76708418ba172b9ff0b28a09cd6 to wayland
   engine.
 
   Added a feature to dump out a png image before calling SwapBuffers.
   To turn on the feature, use the following env vars.
 
   EVAS_GL_SWAP_BUFFER_DEBUG_DIR=dir_name sets the name of the
 directory
   that the files will be output to and enables the debug mode.
 
   EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS=1 will enable the writing of the
   files every frame.  This in effect turns on the swap_buffer_debug
   variable, which can be set on or off in gdb for debugging.  This
 will
   allow dumping of certain frames without having to dump out a ton of
   files to track down one frame.
  ---
src/modules/evas/engines/wayland_egl/evas_engine.c | 43
 ++
1 file changed, 43 insertions(+)
 
  diff --git a/src/modules/evas/engines/wayland_egl/evas_engine.c
 b/src/modules/evas/engines/wayland_egl/evas_engine.c
  index 1db4dbd..65edcca 100644
  --- a/src/modules/evas/engines/wayland_egl/evas_engine.c
  +++ b/src/modules/evas/engines/wayland_egl/evas_engine.c
  @@ -41,6 +41,7 @@ struct _Render_Engine
   Eina_Bool lost_back : 1;
   Eina_Bool end : 1;
   Eina_Bool evgl_initted : 1;
  +   int   frame_cnt;
 
   struct
 {
  @@ -103,6 +104,9 @@ static Eina_Bool extn_have_buffer_age = EINA_TRUE;
static int safe_native = -1;
static int partial_rect_union_mode = -1;
 
  +static int swap_buffer_debug_mode = -1;
  +static int swap_buffer_debug = 0;
  +
/* function tables - filled in later (func and parent func) */
static Evas_Func func, pfunc;
static EVGL_Interface evgl_funcs =
  @@ -1188,6 +1192,7 @@ static void
eng_output_flush(void *data, Evas_Render_Mode render_mode)
{
   Render_Engine *re;
  +   static char *dname = NULL;
 
   if (!(re = (Render_Engine *)data)) return;
 
  @@ -1201,6 +1206,41 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
 
   evas_gl_common_context_done(re-win-gl_context);
 
  +   // Save contents of the framebuffer to a file
  +   if (swap_buffer_debug_mode == -1)
  + {
  +if ((dname = getenv(EVAS_GL_SWAP_BUFFER_DEBUG_DIR)))
  +  {
  + int stat;
  + // Create a directory with 0775 permission
  + stat = mkdir(dname,
 S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
  + if ((!stat) || errno == EEXIST) swap_buffer_debug_mode = 1;
  +  }
  +else
  +   swap_buffer_debug_mode = 0;
  + }
  +
  +   if (swap_buffer_debug_mode == 1)
  + {
  +// Set this env var to dump files every frame
  +// Or set the global var in gdb to 1|0 to turn it on and off
  +if (getenv(EVAS_GL_SWAP_BUFFER_DEBUG_ALWAYS))
  +   swap_buffer_debug = 1;
  +
  +if (swap_buffer_debug)
  +  {
  + char fname[100];
  + int ret = 0;
  + sprintf(fname, %p, (void*)re-win);
  +
  + ret = evas_gl_common_buffer_dump(re-win-gl_context,
  +  (const char*)dname,
  +  (const char*)fname,
  +  re-frame_cnt);
  + if (!ret) swap_buffer_debug_mode = 0;
  +  }
  + }
  +
   if (!re-vsync)
 {
if (re-info-vsync) eglSwapInterval(re-win-egl_disp, 1);
  @@ -1278,6 +1318,9 @@ eng_output_flush(void *data, Evas_Render_Mode
 render_mode)
evas_common_tilebuf_free_render_rects(re-rects);
re-rects = NULL;
 }
  +
  +   re-frame_cnt++;
  +
end:
   evas_gl_preload_render_unlock(eng_gl_preload_make_current, re);
}
 



 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enventor (an edc editor prototype)

2013-07-22 Thread Sung W. Park

Looks really nice hermet! :)

what's wrong with 'enventor'???  it totally makes sense you know, like all
the other names.  i'm surprised that terminology wasn't name eterminology
;-)

cheers,
Sung


On Tue, Jul 23, 2013 at 10:52 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Tue, 23 Jul 2013 02:42:10 +0900 (KST) ChunEon Park her...@naver.com
 said:

  http://www.youtube.com/watch?v=cOdgBBV4J3sfeature=youtu.be

 just call it inventor. enough of the e stuff. it sounds stupid to mangle
 words to stuff an e on the front. we have so much of it that people already
 can't keep track of what is what.

 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] E Korean diner before summer

2013-06-29 Thread Sung W. Park

i'll meet you guys at the restaurant! :)


On Sun, Jun 30, 2013 at 11:34 AM, Jérôme Pinot ngc...@gmail.com wrote:

 On 06/30/13 01:43, Cedric BAIL wrote:
  Yop,
 
  On Wed, Jun 26, 2013 at 5:09 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
   On Wed, Jun 26, 2013 at 11:17 AM, Carsten Haitzler 
 ras...@rasterman.com wrote:
   On Wed, 26 Jun 2013 10:59:39 +0900 Jérôme Pinot ngc...@gmail.com
 said:
   On 06/13/13 14:31, Cedric BAIL wrote:
Hello everyone,
   
Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe
 starting
in the afternoon.
   
Have fun,
--
Cedric BAIL
  
   So the votes went mostly for sunday june 30 in Seoul:
   https://phab.enlightenment.org/V1
  
   Let's do it? At what time/place?
  
  
 https://maps.google.com/maps?q=Brick+Oven+New+York+Pizza+Gangnam+Seoul,+Gangnam-gu,+Seoul,+South+Koreahl=enll=37.502913,127.027694spn=0.00177,0.001971sll=37.503283,127.028019sspn=0.003541,0.003943oq=gangnam+new+yorkhq=Brick+Oven+New+York+Pizza+Gangnam+Seoul,hnear=Gangnam-gu,+Seoul,+South+Koreat=mz=19iwloc=Alayer=ccbll=37.502999,127.02777panoid=9RXWSeBE9zHCxRK9K4f8Jgcbp=12,317.69,,0,-2.46
  
   We need to booked for that place. I am tasking JP for this as a
   homework :-) And maybe earlier we can go to some coffee place.
 
  Let's meet at 5pm in front of exit 11 of Gangnam station and we will
  move from there.
  --
  Cedric BAIL

 OK for me!

 --
 Jérôme Pinot
 http://ngc891.blogdns.net/


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] #2283: GLView works only for OpenGL X11 engine

2013-03-04 Thread Sung W. Park

Hi,

that's really weird..

I'm running Ubuntu 12.04 and I just installed libosmesa6-dev using apt-get
install and it works fine.

Which OSMesa have you tried this on?

I only opened OSMesa in the code because when I implemented it, libosmesa
contained all the GL symbols.

Maybe they separated it?  I guess I'll have to check it  out.

cheers,
Sung

On Tue, Mar 5, 2013 at 1:00 AM, E-Trac t...@enlightenment.org wrote:

 #2283: GLView works only for OpenGL X11 engine
 +-
  Reporter:  Dennis Schridde devurandom@…  |   Owner:  raster
  Type:  Bug |  Status:  new
  Priority:  Major   |   Milestone:
 Component:  evas|  Resolution:
  Keywords:  |  Blocked By:
  Blocking:  |
 +-

 Comment (by Dennis Schridde devurandom@…):

  The same issue exists on Ubuntu 12.04 (actually Bodhi 2.2):
  ERR25811:evas_main evas_gl.c:42 evas_gl_new() Evas GL engine not
  available.
  ERR25811:elementary elm_glview.c:196 _elm_glview_smart_add() Failed
  Creating an Evas GL Object.

 --
 Ticket URL: http://trac.enlightenment.org/e/ticket/2283#comment:3
 Enlightenment http://www.enlightenment.org/
 Enlightenment Project

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_feb
 ___
 enlightenment-bugs mailing list
 enlightenment-b...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-bugs

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [e-users] Korean E dinner

2013-01-09 Thread Sung W. Park

Raster  Hermet doing Gangnam style!  crazy!

by the way, if you guys are gonna try Vatos, I suggest that you call the
place and make a reservation (if possible)... they may be booked already.
otherwise you're looking at an hour wait at least!  but the food is
awesome!

http://blog.naver.com/gmdosk?Redirect=LoglogNo=70154958852

If you're looking for something else, I also would like to recommend New
York Brick Oven Pizza near Gangnam station.

http://blog.naver.com/crom776?Redirect=LoglogNo=150148599787

It's my favorite pizza place in Korea.  The owner was actually trained in
the states and he imports his key ingredients from the states.

i can't join this weekend but have a wonderful time!

cheers,
sung

On Thu, Jan 10, 2013 at 9:57 AM, Kim Shinwoo kimcinoo@gmail.com wrote:

 -,.-)=b

 On Wed, Jan 9, 2013 at 8:26 PM, Jihoon Kim imfin...@gmail.com wrote:

  it's hot video I've ever seen :)
  2013. 1. 6. 오전 12:56에 Daniel Juyung Seo seojuyu...@gmail.com님이 작성:
 
   Everybody pants on!!!
  
   Raster and Hermet actually danced Gangnam Style in Itaewon just for 5
   seconds.
   Let's party.
  
   http://www.youtube.com/watch?v=qyS-HhlXmRE
  
   Daniel Juyung Seo (SeoZ)
  
   On Fri, Jan 4, 2013 at 9:19 PM, Carsten Haitzler ras...@rasterman.com
   wrote:
  
On Fri, 4 Jan 2013 19:27:32 +0900 Cedric BAIL cedric.b...@free.fr
   said:
   
 On Fri, Jan 4, 2013 at 5:21 PM, Carsten Haitzler 
  ras...@rasterman.com
   
wrote:
  On Fri, 4 Jan 2013 15:55:21 +0900 Cedric BAIL 
 cedric.b...@free.fr
  
said:
  On Fri, Jan 4, 2013 at 2:58 PM, Jérôme Pinot ngc...@gmail.com
wrote:
   On 01/04/13 14:51, Daniel Juyung Seo wrote:
   On Fri, Jan 4, 2013 at 2:47 PM, Carsten Haitzler
   ras...@rasterman.comwrote:
On Fri, 4 Jan 2013 13:23:43 +0900 Daniel Juyung Seo
seojuyu...@gmail.com said:
   
gangnam vs itaewon... FIGHT!
   
/me sings itaewon style and dances in a silly fashion.
   
  
   Dance during the meeting :)
   I bring my camera if we meet at Itaewon.
  
   If Raster dances Gangnam style, I would LOVE going to Itaewon
  :-D
 
  Ok, so it will be Itaewon if raster accept to dance Gangnam
 style.
  Hermet can show him how, I already saw him dancing ;-) If not,
  then
  Gangnam.
 
  What times guy ? 7pm ?
 
  yargh... i can dance with my arms. theres never enough room to
 use
   your
  legs... :)

 We will find the necessary room for that. So Itaewon tomorrow at 7
 at
 the subway exit in front of Paris baguette.
   
i shall try remember my pants. u'll need to be fast with the camera.
dancing
may not last long. ;)
   
--
- Codito, ergo sum - I code, therefore I am
  --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
   
   
   
   
  
 
 --
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and
  experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
enlightenment-users mailing list
enlightenment-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
   
  
  
 
 --
   Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
   MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
   with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
   MVPs and experts. SALE $99.99 this month only -- learn more at:
   http://p.sf.net/sfu/learnmore_122912
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
 
 
 --
  Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
  and much more. Keep your Java skills current with LearnJavaNow -
  200+ hours of step-by-step video tutorials by Java experts.
  SALE $49.99 this month only -- learn more at:
  http://p.sf.net/sfu/learnmore_122612
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 

 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. ON SALE this month only --

Re: [E-devel] E SVN: sung IN trunk/efl: . src src/modules/evas/engines/gl_common

2013-01-07 Thread Sung W. Park

Leadro,

yes, they need to be invalidated.  The times that it would really matter is
when your GL driver is updated with some new fbo surface features or if you
change GPUs entirely, hence changing drivers.  I'm thinking about adding GL
driver name/version as a means to invalidate them.  Let me know if you have
other suggestions.

Daniel,

All I did with the shader stuff was to take the functions out so I can
share them.  I know that evas_gl isn't used in E so I would be surprised to
find out that it would cause crashes... plush my E was running fine when I
applied the changes but i'll have to take a look.

cheers,
Sung




On Mon, Jan 7, 2013 at 9:33 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote:

 Maybe.. is this the reason why I got e17 crashes on shader stuff?
 It crashed a lot today.

 #27 0xb36121a9 in shader_array_flush (gc=0xa189950)
 at modules/evas/engines/gl_common/evas_gl_context.c:2774
 texuv_ptr = 0xf000 Address 0xf000 out of bounds
 texuv3_ptr = 0x27000 Address 0x27000 out of bounds
 vertex_ptr = optimized out
 color_ptr = 0x9000 Address 0x9000 out of bounds
 texuv2_ptr = 0x1b000 Address 0x1b000 out of bounds
 texm_ptr = 0x33000 Address 0x33000 out of bounds
 i = optimized out
 gw = 1680
 cy = optimized out
 fbo = 0
 done = 1
 gh = 1050
 setclip = optimized out

 You can find full crash dump from here.
 http://www.enlightenment.org/~seoz/e-crashdump.txt

 Thanks.

 Daniel Juyung Seo (SeoZ)

 On Mon, Jan 7, 2013 at 9:12 PM, Leandro Dorileo dori...@profusion.mobi
 wrote:

  Hi,
 
  On Sun, Jan 06, 2013 at 10:16:18PM -0800, Enlightenment SVN wrote:
   Log:
   Pulled out evas gl backend binary shader file caching code from
 evas_gl_shader.c file and made an internal generic caching api in
 evas_gl_common.h for use in other places ie. evas_gl.
  
 Then implemented evas_gl surface cap. caching code in gl backend to
 accelerate the engine creation.
  
  
  
   Author:   sung
   Date: 2013-01-06 22:16:18 -0800 (Sun, 06 Jan 2013)
   New Revision: 82321
   Trac: http://trac.enlightenment.org/e/changeset/82321
  
   Added:
 trunk/efl/src/modules/evas/engines/gl_common/evas_gl_file_cache.c
   Modified:
 trunk/efl/ChangeLog trunk/efl/src/Makefile_Evas.am
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_core.c
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_shader.c
  
   Modified: trunk/efl/ChangeLog
   ===
   --- trunk/efl/ChangeLog   2013-01-07 06:06:16 UTC (rev 82320)
   +++ trunk/efl/ChangeLog   2013-01-07 06:16:18 UTC (rev 82321)
   @@ -1,3 +1,12 @@
   +2013-01-07 Sung W. Park (sung_)
   +
   + * Pulled out evas gl backend binary shader file caching code from
   +evas_gl_shader.c file and made an internal generic caching api
  in
   +evas_gl_common.h for use in evas_gl code.
   +* Implemented evas_gl surface cap. caching code in gl backend
 to
   +accelerate the engine creation.
   +
   +
2013-01-07  Thomas Petazzoni
  
 * Fix build of Evas XCB backend.
  
   Modified: trunk/efl/src/Makefile_Evas.am
   ===
   --- trunk/efl/src/Makefile_Evas.am2013-01-07 06:06:16 UTC (rev
 82320)
   +++ trunk/efl/src/Makefile_Evas.am2013-01-07 06:16:18 UTC (rev
 82321)
   @@ -448,6 +448,7 @@
modules/evas/engines/gl_common/evas_gl_private.h \
modules/evas/engines/gl_common/evas_gl_common.h \
modules/evas/engines/gl_common/evas_gl_context.c \
   +modules/evas/engines/gl_common/evas_gl_file_cache.c \
modules/evas/engines/gl_common/evas_gl_shader.c \
modules/evas/engines/gl_common/evas_gl_rectangle.c \
modules/evas/engines/gl_common/evas_gl_texture.c \
  
   Modified: trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
   ===
   --- trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  2013-01-07 06:06:16 UTC (rev 82320)
   +++ trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  2013-01-07 06:16:18 UTC (rev 82321)
   @@ -555,6 +555,15 @@
void  evas_gl_common_shader_program_init_done(void);
void
   evas_gl_common_shader_program_shutdown(Evas_GL_Program *p);
  
   +Eina_Bool evas_gl_common_file_cache_is_dir(const char *file);
   +Eina_Bool evas_gl_common_file_cache_mkdir(const char *dir);
   +Eina_Bool evas_gl_common_file_cache_file_exists(const char
  *file);
   +Eina_Bool evas_gl_common_file_cache_mkpath_if_not_exists(const
  char *path);
   +Eina_Bool evas_gl_common_file_cache_mkpath(const char *path);
   +int   evas_gl_common_file_cache_dir_check(char *cache_dir,
  int num);
   +int

Re: [E-devel] E SVN: sung IN trunk/efl: . src src/modules/evas/engines/gl_common

2013-01-07 Thread Sung W. Park

Leandro,

nevermind the last comment.   It creates a new file based on the driver
already so it shouldn't have issues with new drivers and gpus.  It's
basically using the same mechanism as the binary shader so it should be
fine.  i got confused for a sec.

thanks for pointing it out though.

cheers,
Sung

On Tue, Jan 8, 2013 at 9:53 AM, Sung W. Park sung...@gmail.com wrote:

 Leadro,

 yes, they need to be invalidated.  The times that it would really matter
 is when your GL driver is updated with some new fbo surface features or if
 you change GPUs entirely, hence changing drivers.  I'm thinking about
 adding GL driver name/version as a means to invalidate them.  Let me know
 if you have other suggestions.

 Daniel,

 All I did with the shader stuff was to take the functions out so I can
 share them.  I know that evas_gl isn't used in E so I would be surprised to
 find out that it would cause crashes... plush my E was running fine when I
 applied the changes but i'll have to take a look.

 cheers,
 Sung




 On Mon, Jan 7, 2013 at 9:33 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote:

 Maybe.. is this the reason why I got e17 crashes on shader stuff?
 It crashed a lot today.

 #27 0xb36121a9 in shader_array_flush (gc=0xa189950)
 at modules/evas/engines/gl_common/evas_gl_context.c:2774
 texuv_ptr = 0xf000 Address 0xf000 out of bounds
 texuv3_ptr = 0x27000 Address 0x27000 out of bounds
 vertex_ptr = optimized out
 color_ptr = 0x9000 Address 0x9000 out of bounds
 texuv2_ptr = 0x1b000 Address 0x1b000 out of bounds
 texm_ptr = 0x33000 Address 0x33000 out of bounds
 i = optimized out
 gw = 1680
 cy = optimized out
 fbo = 0
 done = 1
 gh = 1050
 setclip = optimized out

 You can find full crash dump from here.
 http://www.enlightenment.org/~seoz/e-crashdump.txt

 Thanks.

 Daniel Juyung Seo (SeoZ)

 On Mon, Jan 7, 2013 at 9:12 PM, Leandro Dorileo dori...@profusion.mobi
 wrote:

  Hi,
 
  On Sun, Jan 06, 2013 at 10:16:18PM -0800, Enlightenment SVN wrote:
   Log:
   Pulled out evas gl backend binary shader file caching code from
 evas_gl_shader.c file and made an internal generic caching api in
 evas_gl_common.h for use in other places ie. evas_gl.
  
 Then implemented evas_gl surface cap. caching code in gl backend to
 accelerate the engine creation.
  
  
  
   Author:   sung
   Date: 2013-01-06 22:16:18 -0800 (Sun, 06 Jan 2013)
   New Revision: 82321
   Trac: http://trac.enlightenment.org/e/changeset/82321
  
   Added:
 trunk/efl/src/modules/evas/engines/gl_common/evas_gl_file_cache.c
   Modified:
 trunk/efl/ChangeLog trunk/efl/src/Makefile_Evas.am
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_core.c
  trunk/efl/src/modules/evas/engines/gl_common/evas_gl_shader.c
  
   Modified: trunk/efl/ChangeLog
   ===
   --- trunk/efl/ChangeLog   2013-01-07 06:06:16 UTC (rev 82320)
   +++ trunk/efl/ChangeLog   2013-01-07 06:16:18 UTC (rev 82321)
   @@ -1,3 +1,12 @@
   +2013-01-07 Sung W. Park (sung_)
   +
   + * Pulled out evas gl backend binary shader file caching code
 from
   +evas_gl_shader.c file and made an internal generic caching
 api
  in
   +evas_gl_common.h for use in evas_gl code.
   +* Implemented evas_gl surface cap. caching code in gl
 backend to
   +accelerate the engine creation.
   +
   +
2013-01-07  Thomas Petazzoni
  
 * Fix build of Evas XCB backend.
  
   Modified: trunk/efl/src/Makefile_Evas.am
   ===
   --- trunk/efl/src/Makefile_Evas.am2013-01-07 06:06:16 UTC (rev
 82320)
   +++ trunk/efl/src/Makefile_Evas.am2013-01-07 06:16:18 UTC (rev
 82321)
   @@ -448,6 +448,7 @@
modules/evas/engines/gl_common/evas_gl_private.h \
modules/evas/engines/gl_common/evas_gl_common.h \
modules/evas/engines/gl_common/evas_gl_context.c \
   +modules/evas/engines/gl_common/evas_gl_file_cache.c \
modules/evas/engines/gl_common/evas_gl_shader.c \
modules/evas/engines/gl_common/evas_gl_rectangle.c \
modules/evas/engines/gl_common/evas_gl_texture.c \
  
   Modified:
 trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
   ===
   --- trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  2013-01-07 06:06:16 UTC (rev 82320)
   +++ trunk/efl/src/modules/evas/engines/gl_common/evas_gl_common.h
  2013-01-07 06:16:18 UTC (rev 82321)
   @@ -555,6 +555,15 @@
void  evas_gl_common_shader_program_init_done(void);
void
   evas_gl_common_shader_program_shutdown(Evas_GL_Program *p);
  
   +Eina_Bool evas_gl_common_file_cache_is_dir(const char *file);
   +Eina_Bool

Re: [E-devel] [e] evas bad typedef

2012-10-04 Thread Sung W. Park

I'll look into it and fix it.

thanks.
Sung

On Fri, Oct 5, 2012 at 5:02 AM, rustyBSD rusty...@gmx.fr wrote:

 Le 01/10/2012 19:08, rustyBSD a écrit :
  Hi,
  == evas_gl_api_ext.h l.4 ==
  The GLchar type is already defined on openbsd
  (/usr/X11R6/include/GL/glext.h), so it has to
  be renamed.

 You should really use another name.GLchar
 already comes with gl/opengl.

 OpenBSD and NetBSD don't like that.

 --
 Don't let slow site performance ruin your business. Deploy New Relic APM
 Deploy New Relic app performance management and know exactly
 what is happening inside your Ruby, Python, PHP, Java, and .NET app
 Try New Relic at no cost today and get our sweet Data Nerd shirt too!
 http://p.sf.net/sfu/newrelic-dev2dev
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

2012-09-18 Thread Sung W. Park

Hi Chris,

Thanks for the fast review. :)

On Tue, Sep 18, 2012 at 4:17 PM, Christopher Michael cp.mich...@samsung.com
 wrote:

 Hi Sung,

 Initial review of this:

 Short version, it looks good :) but found some problems in you're patch:

 In the evgl_eng_window_surface_create for the GLES_VARIETY_SGX path:

 +   surface = eglCreateWindowSurface(re-**win-egl_disp,
 +re-win-egl_config,
 + (EGLNativeWindowType)**DefaultRootWindow(re-info-**info.display),
 +NULL);

 DefaultRootWindow is an X11 function. This will fail for wayland_egl.
 Better to use re-win-win here IMO.


I can fix that easily. I can't remember why I did it this way to tell you
the truth.



 Also, I noticed in some places that we are still using
 glsym_eglQueryString and glXQueryString. Wouldn't it be better if Evas_GL
 provided a QueryString function ? This way the various backends could call
 which ever querystring function they use ? (Same for GetProcAddress).
 Basically, the EVGL_Interface could provide 2 more methods. QueryString and
 GetProcAddress.


What do you mean by some places? In evas_engine? or evas_gl_core?

I actually tried to remove all the EGL/GLX dependencies from the Evas_GL
part of the code.  That way, evas_engine can handle with the glue layer
stuff and evas_gl_core would only need to handle with GL. That's the reason
why evas_engine has to provide these two functions to evas_gl_core.  It's
part of the engine interface.

Maybe I misunderstood you?



 Other than that, I Like It :) It removes a lot of duplicated code and is
 good (in general).

 I agree.  I like it a lot better as well (in general) ;-)


 Cheers,
 dh


I'll wait for Carsten to take a look at it as well and then push it up.

Thanks!
Sung



 On 17/09/12 10:52, Sung W. Park wrote:

 Hi all,

 I'd like to ask you devs for review on Evas_GL that I've recently
 refactored
 before I push it upstream.

 evas_gl was introduced last year and it has gotten really messy over the
 year
 with a lot of little tweaks here and there.

 Also, I've noticed not too long ago that the same code was pretty much
 being
 copied over to wayland_egl engine and so I've decided that it's about time
 to
 rewrite the ugly code.

 I've commonized the GL part of the code and made an interface that
 each engine has to implement to get the evas_gl running.  In the overall
 scheme of things, one can argue whether this was the best design but with
 what we have currently, i thought it was reasonable.

 I'm attaching a patch that modifies the following files...

 src/modules/engines/gl_common/**Makefile.am
 src/modules/engines/gl_x11/**evas_engine.c

 and I've added 7 new files in gl_common.

 src/modules/engines/gl_common/**evas_gl_core_private.h
 src/modules/engines/gl_common/**evas_gl_core.h
 src/modules/engines/gl_common/**evas_gl_core.c
 src/modules/engines/gl_common/**evas_gl_api.c
 src/modules/engines/gl_common/**evas_gl_api_ext_def.h
 src/modules/engines/gl_common/**evas_gl_api_ext.h
 src/modules/engines/gl_common/**evas_gl_api_ext.c

 I'm also including two samples files as well as a PPT slides I've
 made for some people here.

 Your comments would be greatly appreciated.

 cheers,
 Sung



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

2012-09-18 Thread Sung W. Park

On Tue, Sep 18, 2012 at 8:21 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 17 Sep 2012 18:52:06 +0900 Sung W. Park sung...@gmail.com
 said:

 you might want to check your compile warnings. :) like...

 evas_engine.c:2620:1: warning: no return statement in function returning
 non-void


yeah, I caught this afterwards. :)




 :) other fun like unused parameters in evas_gl_api.c ...


actually, I did run the compiler flag with all the warnings on and some of
the variables come as unused because they're only used on target (with the
#ifdef GLES_VARIETY_...).  Any thoughts or suggestions on this?


 hint:

 export CFLAGS=-W -Wall -Wextra

 :)


 and yes even tho the eglCreateWindowSurface() using root is not portable to
 wayland. it is in gl_x11 which means its bound to x11. so thats ok. i
 don't see
 what else could have been done. if the egl/glx stuff was virtualized to be
 shared then yes - it'd be a problem. :)

 evas_engine.c has lost like 2000 lines of code. that's good! :)

 i say put it in and clean up the nigglies (formatting etc.) then live. :)


will do.  thanks~!



  Hi all,
 
  I'd like to ask you devs for review on Evas_GL that I've recently
 refactored
  before I push it upstream.
 
  evas_gl was introduced last year and it has gotten really messy over the
  year
  with a lot of little tweaks here and there.
 
  Also, I've noticed not too long ago that the same code was pretty much
  being
  copied over to wayland_egl engine and so I've decided that it's about
 time
  to
  rewrite the ugly code.
 
  I've commonized the GL part of the code and made an interface that
  each engine has to implement to get the evas_gl running.  In the overall
  scheme of things, one can argue whether this was the best design but with
  what we have currently, i thought it was reasonable.
 
  I'm attaching a patch that modifies the following files...
 
  src/modules/engines/gl_common/Makefile.am
  src/modules/engines/gl_x11/evas_engine.c
 
  and I've added 7 new files in gl_common.
 
  src/modules/engines/gl_common/evas_gl_core_private.h
  src/modules/engines/gl_common/evas_gl_core.h
  src/modules/engines/gl_common/evas_gl_core.c
  src/modules/engines/gl_common/evas_gl_api.c
  src/modules/engines/gl_common/evas_gl_api_ext_def.h
  src/modules/engines/gl_common/evas_gl_api_ext.h
  src/modules/engines/gl_common/evas_gl_api_ext.c
 
  I'm also including two samples files as well as a PPT slides I've
  made for some people here.
 
  Your comments would be greatly appreciated.
 
  cheers,
  Sung


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas_GL Refactored Code

2012-09-18 Thread Sung W. Park

On Tue, Sep 18, 2012 at 9:14 PM, Christopher Michael cp.mich...@samsung.com
 wrote:

 On 18/09/12 12:21, Carsten Haitzler (The Rasterman) wrote:
  On Mon, 17 Sep 2012 18:52:06 +0900 Sung W. Park sung...@gmail.com
 said:
 
  you might want to check your compile warnings. :) like...
 
  evas_engine.c:2620:1: warning: no return statement in function returning
  non-void
 
  :) other fun like unused parameters in evas_gl_api.c ...
 
  hint:
 
  export CFLAGS=-W -Wall -Wextra
 
  :)
 
 
  and yes even tho the eglCreateWindowSurface() using root is not portable
 to
  wayland. it is in gl_x11 which means its bound to x11. so thats ok. i
 don't see
  what else could have been done. if the egl/glx stuff was virtualized to
 be
  shared then yes - it'd be a problem. :)

 I was under the impression that the patch was to address virtualization
 to reduce duplicated code...



I guess maybe I wasn't completely clear.

Yes, I am handling the duplicate code.  What I have done is separate all
the GL code with EGL/GLX (platform dependent) code.  All the GL code is
implemented in gl_common/ under evas_gl_core and etc. and the platform
dependent parts are implemented in evas_engine.c as engine functions.   So,
for waylaind_egl engine, you'd have to implement those parts, although
technically you can copy and paste the egl part from gl_x11 engine with a
few minor tweaks.  At least this will get rid of 2000 lines of duplicate
code in evas_engine. :-) I can help you try to port it over to wayland_egl
engine.. although I won't be able to test it.

Let me know if you questions.
Sung



 dh

 
  evas_engine.c has lost like 2000 lines of code. that's good! :)
 
  i say put it in and clean up the nigglies (formatting etc.) then live. :)
 
  Hi all,
 
  I'd like to ask you devs for review on Evas_GL that I've recently
 refactored
  before I push it upstream.
 
  evas_gl was introduced last year and it has gotten really messy over the
  year
  with a lot of little tweaks here and there.
 
  Also, I've noticed not too long ago that the same code was pretty much
  being
  copied over to wayland_egl engine and so I've decided that it's about
 time
  to
  rewrite the ugly code.
 
  I've commonized the GL part of the code and made an interface that
  each engine has to implement to get the evas_gl running.  In the overall
  scheme of things, one can argue whether this was the best design but
 with
  what we have currently, i thought it was reasonable.
 
  I'm attaching a patch that modifies the following files...
 
  src/modules/engines/gl_common/Makefile.am
  src/modules/engines/gl_x11/evas_engine.c
 
  and I've added 7 new files in gl_common.
 
  src/modules/engines/gl_common/evas_gl_core_private.h
  src/modules/engines/gl_common/evas_gl_core.h
  src/modules/engines/gl_common/evas_gl_core.c
  src/modules/engines/gl_common/evas_gl_api.c
  src/modules/engines/gl_common/evas_gl_api_ext_def.h
  src/modules/engines/gl_common/evas_gl_api_ext.h
  src/modules/engines/gl_common/evas_gl_api_ext.c
 
  I'm also including two samples files as well as a PPT slides I've
  made for some people here.
 
  Your comments would be greatly appreciated.
 
  cheers,
  Sung
 
 



 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] new evas compile warnings

2012-08-18 Thread Sung W. Park

Hi Mike,

Thanks for pointing out those warnings.  I will get on them as soon as I
get back.
I've been traveling for the past two weeks and I won't be back until
Monday.
They really should not have gotten in there in the first place.

Evas_GL has been getting really messy over the past year with workarounds,
optimizations, and bug fixes so I am actually in the process of rewriting
them so that the
common code can be shared among different engines: ie. wayland and gl_x11.

It'll be a lot cleaner for sure.

thanks.
Sung


On Saturday, August 18, 2012, Michael Blumenkrantz wrote:

 Making all in gl_common
   CC   evas_gl_context.lo
   CC   evas_gl_shader.lo
   CC   evas_gl_rectangle.lo
   CC   evas_gl_texture.lo
   CC   evas_gl_image.lo
   CC   evas_gl_font.lo
   CC   evas_gl_polygon.lo
   CC   evas_gl_line.lo
   CC   evas_gl_filter.lo
 evas_gl_texture.c: In function '_tex_2d':
 evas_gl_texture.c:119:8: warning: the address of 'glGetTexLevelParameteriv'
 will always evaluate as 'true' CCLD libevas_engine_gl_common.la
 Making all in gl_x11
   CC   module_la-evas_engine.lo
   CC   module_la-evas_x_main.lo
 evas_engine.c: In function '_gl_ext_sym_init':
 evas_engine.c:542:115: warning: assignment from incompatible pointer type
 evas_engine.c:542:273: warning: assignment from incompatible pointer type
 evas_engine.c: In function 'eng_image_map_clean':
 evas_engine.c:2836:27: warning: unused parameter 'data'
 evas_engine.c:2836:43: warning: unused parameter 'm'
 evas_engine.c: In function '_print_gl_surface_info':
 evas_engine.c:3067:137: warning: cast from pointer to integer of different
 size
 evas_engine.c:3067:284: warning: cast from pointer to integer of different
 size
 evas_engine.c:3071:148: warning: cast from pointer to integer of different
 size
 evas_engine.c:3071:319: warning: cast from pointer to integer of different
 size
 evas_engine.c: In function '_set_gl_surface_cap':
 evas_engine.c:3131:28: warning: unused variable 'stencil'
 evas_engine.c:3131:21: warning: unused variable 'depth'
 evas_engine.c:3131:16: warning: unused variable 'tex'
 evas_engine.c:3131:11: warning: unused variable 'fbo'
 evas_engine.c: In function '_set_internal_config':
 evas_engine.c:3315:33: warning: comparison between signed and unsigned
 integer
 expressions evas_engine.c:3316:33: warning: comparison between signed and
 unsigned integer expressions evas_engine.c: In function
 '_create_rt_buffers':
 evas_engine.c:3557:4: warning: pointer targets in passing argument 2 of
 'glGetIntegerv' differ in signedness /usr/include/GL/gl.h:842:45: note:
 expected 'GLint *' but argument is of type 'GLuint *' evas_engine.c: In
 function 'eng_gl_surface_create': evas_engine.c:3588:31: warning: unused
 variable 'rsc' evas_engine.c: In function 'eng_gl_surface_destroy':
 evas_engine.c:3682:31: warning: unused variable 'rsc'
 evas_engine.c: In function 'eng_gl_context_destroy':
 evas_engine.c:3827:31: warning: unused variable 'rsc'
 evas_engine.c: In function 'eng_gl_make_current':
 evas_engine.c:3969:30: warning: comparison between signed and unsigned
 integer
 expressions evas_engine.c: In function 'evgl_glGetShaderPrecisionFormat':
 evas_engine.c:4415:40: warning: unused parameter 'shadertype'
 evas_engine.c:4415:59: warning: unused parameter 'precisiontype'
   CCLD module.la


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: sung trunk/evas/src/lib

2012-05-21 Thread Sung W. Park

yeah.. i don't like that kind of stuff either.  but as Carsten said, it was
out of necessity.  :-(

Sung

On Tue, May 22, 2012 at 8:39 AM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 21 May 2012 14:36:17 +0200 Vincent Torri vincent.to...@gmail.com
 said:

  On Mon, May 21, 2012 at 1:51 PM, Carsten Haitzler ras...@rasterman.com
  wrote:
   On Mon, 21 May 2012 10:04:06 +0200 Vincent Torri 
 vincent.to...@gmail.com
   said:
  
   this code is actually right.
 
  i didn't say that it was wrong. I just said that i don't like that
  kind of stuff.

 but in this situation its kind of a necessity to avoid bizarre compile
 issues.

   evas_gl.h conflicts with gl headers - they are
   mutually exclusive since evas_gl is a one-stop shop for gl stuff when
 using
   it with evas1 - that includes all gl defines and so on.
  
   i don't like that kind of stuff at all (not only your commit, but the
   inclusion of specific gl headers).
  
   Vincent
  
   On Mon, May 21, 2012 at 10:01 AM, Enlightenment SVN
   no-re...@enlightenment.org wrote:
Log:
Separated checks for gl2.h defines and gl2ext.h defines in
 Evas_GL.h.
   
   
Author:   sung
Date: 2012-05-21 01:01:28 -0700 (Mon, 21 May 2012)
New Revision: 71270
Trac: http://trac.enlightenment.org/e/changeset/71270
   
Modified:
 trunk/evas/src/lib/Evas_GL.h
   
Modified: trunk/evas/src/lib/Evas_GL.h
===
--- trunk/evas/src/lib/Evas_GL.h2012-05-21 07:51:41 UTC (rev
71269) +++ trunk/evas/src/lib/Evas_GL.h2012-05-21 08:01:28
 UTC
(rev 71270) @@ -1038,6 +1038,17 @@
   
 #define GL_INVALID_FRAMEBUFFER_OPERATION  0x0506
   
+#else
+# ifndef EVAS_GL_NO_GL_H_CHECK
+#  error You may only include either Evas_GL.h OR use your native
OpenGL's headers. If you use Evas to do GL, then you cannot use the
native gl headers. +# endif +#endif
+
+
+#if !defined(__glext_h_)  !defined(__gl2ext_h_)
+# define __glext_h_
+# define __gl2ext_h_
+
 //---//
 // GLES extension defines
   
   
   
   
 --
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
 Discussions
will include endpoint security, mobile security and the latest in
 malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-svn mailing list
enlightenment-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
  
  
 --
   Live Security Virtual Conference
   Exclusive live event will cover all the ways today's security and
   threat landscape has changed and how IT managers can respond.
 Discussions
   will include endpoint security, mobile security and the latest in
 malware
   threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
   ___
   enlightenment-devel mailing list
   enlightenment-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
  
  
  
   --
   - Codito, ergo sum - I code, therefore I am
 --
   The Rasterman (Carsten Haitzler)ras...@rasterman.com
  
 
 
 --
  Live Security Virtual Conference
  Exclusive live event will cover all the ways today's security and
  threat landscape has changed and how IT managers can respond. Discussions
  will include endpoint security, mobile security and the latest in malware
  threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
  ___
  enlightenment-devel mailing list
  enlightenment-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com



 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Live Security

Re: [E-devel] E SVN: sung IN trunk/evas: . src/lib src/modules/engines/gl_x11

2012-05-16 Thread Sung W. Park

Hi Vincent,

I didn't realize I was neglecting the NEWS.  I guess someone was covering
my rear all this time.  Thanks for getting the previous stuff in there to
whoever it was.  I'll get on it along with updating the Evas_GL. h.

Thanks for pointing that out.

cheers,
Sung

On Thu, May 17, 2012 at 6:46 AM, Vincent Torri vincent.to...@gmail.comwrote:

 missing doc for the new code in Evas_GL.h (don't forget @since)

 NEWS file, please

 Vincent

 On Mon, May 14, 2012 at 10:52 AM, Enlightenment SVN
 no-re...@enlightenment.org wrote:
  Log:
  Adding MSAA (Multisample Anti-Aliased) Surface Option to Evas GL.
   Currently, this feature is only supported in EGL/GLESv2 environment
   with GL_IMG_multisampled_render_to_texture extension supported.
 
   _
 
   from:(sanghee park) sh15.p...@samsung.com
 
   Dear all,
 
I compose this mail to ask reviewal this patch about multisampling
 on the evasgl.
I want to make multisampling capacity to enhance rendering quality
 of the evasgl.
But if MSAA is applied always, this have possibility lowering
 rendering performance,
I separated user's input level to high, mid, low, none.
If you want to test this patch, try to examine rendering qulity on
 EGL circumstance with multisampling level.
Plaese review it, and any suggestion will be appreciated.
 
Best Regards,
SangHee
 
 
 
 
 
 
  Author:   sung
  Date: 2012-05-14 01:52:56 -0700 (Mon, 14 May 2012)
  New Revision: 70992
  Trac: http://trac.enlightenment.org/e/changeset/70992
 
  Modified:
   trunk/evas/ChangeLog trunk/evas/src/lib/Evas_GL.h
 trunk/evas/src/modules/engines/gl_x11/evas_engine.c
 
  Modified: trunk/evas/ChangeLog
  ===
  --- trunk/evas/ChangeLog2012-05-14 08:21:48 UTC (rev 70991)
  +++ trunk/evas/ChangeLog2012-05-14 08:52:56 UTC (rev 70992)
  @@ -731,9 +731,15 @@
 * Add CServe2 and image cache2 that makes use of it. Several
 changes
 in the buffer and software engines to use the right cache if
 CServe2
 is requested for the application.
  -
  +
   2012-05-14  Carsten Haitzler (The Rasterman)
 
  * Fix pixman rendering support if you set alpha flag AFTER
  setting image size for custom image data.
 
  +2012-05-14 Sanghee Park
  +
  +   * Add Multisample Anti-Anliased surface format for Evas GL.
  +The formats are divided into High, Med, Low, None, where High
 represent
  +max number of samples.  Currently, this feature is only
 supported in GLES2
  +environment with GL_IMG_multisampled_render_to_texture
 extension supported.
 
  Modified: trunk/evas/src/lib/Evas_GL.h
  ===
  --- trunk/evas/src/lib/Evas_GL.h2012-05-14 08:21:48 UTC (rev
 70991)
  +++ trunk/evas/src/lib/Evas_GL.h2012-05-14 08:52:56 UTC (rev
 70992)
  @@ -47,12 +47,21 @@
 EVAS_GL_OPTIONS_DIRECT  = (10)
   } Evas_GL_Options_Bits;
 
  +typedef enum _Evas_GL_Multisample_Bits
  +{
  +   EVAS_GL_MULTISAMPLE_NONE = 0,
  +   EVAS_GL_MULTISAMPLE_LOW  = 1,
  +   EVAS_GL_MULTISAMPLE_MED  = 2,
  +   EVAS_GL_MULTISAMPLE_HIGH = 3
  +} Evas_GL_Multisample_Bits;
  +
   struct _Evas_GL_Config
   {
  -   Evas_GL_Color_Format color_format;
  -   Evas_GL_Depth_Bits   depth_bits;
  -   Evas_GL_Stencil_Bits stencil_bits;
  -   Evas_GL_Options_Bits options_bits;
  +   Evas_GL_Color_Format   color_format;
  +   Evas_GL_Depth_Bits depth_bits;
  +   Evas_GL_Stencil_Bits   stencil_bits;
  +   Evas_GL_Options_Bits   options_bits;
  +   Evas_GL_Multisample_Bits   multisample_bits;
   };
 
   #define EVAS_GL_EXTENSIONS   1
  @@ -1122,6 +1131,12 @@
   #define GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG 0x8C02
   #define GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG 0x8C03
 
  +/* GL_IMG_multisampled_render_to_texture */
  +#define GL_RENDERBUFFER_SAMPLES_IMG 0x9133
  +#define GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE_IMG   0x9134
  +#define GL_MAX_SAMPLES_IMG  0x9135
  +#define GL_TEXTURE_SAMPLES_IMG  0x9136
  +
 
  /**
   * NV extension tokens
 
  **/
 
  Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
  ===
  --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-14
 08:21:48 UTC (rev 70991)
  +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-14
 08:52:56 UTC (rev 70992)
  @@ -43,21 +43,26 @@
 
 // GL Surface Capability
 struct {
  -int rgb_fmt;
  -int rgba_fmt;
  +int max_rb_size;
  +int

Re: [E-devel] [Patch]Enable multisampling capacity on the evasgl

2012-05-14 Thread Sung W. Park

Hi Sanghee,

I think we'll have to come up with a better way to differentiate between
Low,
Med, High in the future although...  I do recognize that the
GL_IMG_multisampled_render_to_texture isn't necessarily the best written GL
extension.  You can't exactly tell at what sample the driver is rendering.

Anyway, the patch looks fine and I've tested it on an EGL target to verify
that it
works.

In svn! Thanks for the patch.

cheers,
Sung


On Mon, May 14, 2012 at 2:22 PM, sanghee park sh15.p...@samsung.com wrote:

 Dear all,

 I compose this mail to ask reviewal this patch about multisampling on the
 evasgl.
 I want to make multisampling capacity to enhance rendering quality of the
 evasgl.
 But if MSAA is applied always, this have possibility lowering rendering
 performance,
 I separated user's input level to high, mid, low, none.
 If you want to test this patch, try to examine rendering qulity on EGL
 circumstance with multisampling level.
 Plaese review it, and any suggestion will be appreciated.

 Best Regards,
 SangHee

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: tasn IN trunk/evas/src: lib lib/canvas modules/engines/gl_x11

2012-05-02 Thread Sung W. Park

hmm... ok, I guess something went wrong somewhere.  I'll try a clean build
tomorrow before resubmitting it.

sorry about the trouble.

-Sung

On Wed, May 2, 2012 at 8:07 PM, Enlightenment SVN 
no-re...@enlightenment.org wrote:

 Log:
 Revert Cleaned up some evas_gl code and added surface cap feature.

  This reverts commit 70617.

  According to stefan_schmidt, reverting this fixes compilation errors.

 Author:   tasn
 Date: 2012-05-02 04:07:29 -0700 (Wed, 02 May 2012)
 New Revision: 70624
 Trac: http://trac.enlightenment.org/e/changeset/70624

 Modified:
  trunk/evas/src/lib/Evas_GL.h trunk/evas/src/lib/canvas/evas_gl.c
 trunk/evas/src/modules/engines/gl_x11/evas_engine.c

 Modified: trunk/evas/src/lib/Evas_GL.h
 ===
 --- trunk/evas/src/lib/Evas_GL.h2012-05-02 10:54:14 UTC (rev 70623)
 +++ trunk/evas/src/lib/Evas_GL.h2012-05-02 11:07:29 UTC (rev 70624)
 @@ -2,6 +2,7 @@
  #define _EVAS_GL_H

  #include Evas.h
 +//#include GL/gl.h

  #ifdef __cplusplus
  extern C {
 @@ -421,11 +422,6 @@
  * @param w The width of the surface.
  * @param h The height of the surface.
  * @return The created GL surface object, or NULL on failure.
 - *
 - * The surface_create function internally finds the closest surface
 - * configureation that matches the input config. The function then
 internally
 - * sets the input config parameters to the configuratoin that was actually
 - * used to create the surface.
  */
  EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL
 *evas_gl, Evas_GL_Config *cfg, int w, int h) EINA_WARN_UNUSED_RESULT
 EINA_ARG_NONNULL(1,2);


 Modified: trunk/evas/src/lib/canvas/evas_gl.c
 ===
 --- trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 10:54:14 UTC (rev 70623)
 +++ trunk/evas/src/lib/canvas/evas_gl.c 2012-05-02 11:07:29 UTC (rev 70624)
 @@ -39,7 +39,7 @@

if (!evas_gl-evas-engine.func-gl_context_create)
  {
 -ERR(Evas GL engine not available.);
 +ERR(GL engine not available\n);
 free(evas_gl);
 return NULL;
  }
 @@ -96,7 +96,7 @@

if (!config)
  {
 -ERR(Invalid Config Pointer!);
 +ERR(Invalid Config\n);
 return NULL;
  }

 @@ -108,7 +108,7 @@

if (!surf-data)
  {
 -ERR(Failed creating a surface from the engine.);
 +ERR(Failed creating a surface from the engine\n);
 free(surf);
 return NULL;
  }
 @@ -129,7 +129,7 @@

if (!surf)
  {
 -ERR(Trying to destroy a NULL surface pointer!);
 +ERR(Trying to destroy a NULL surface pointer!\n);
 return;
  }

 @@ -158,7 +158,7 @@
ctx = calloc(1, sizeof(Evas_GL_Context));
if (!ctx)
  {
 -ERR(Unable to create a Evas_GL_Context object);
 +ERR(Unable to create a Evas_GL_Context object\n);
 return NULL;
  }

 @@ -175,7 +175,7 @@
// Set a few variables
if (!ctx-data)
  {
 -ERR(Failed creating a context from the engine.);
 +ERR(Failed creating a context from the engine\n);
 free(ctx);
 return NULL;
  }
 @@ -197,7 +197,7 @@

if (!ctx)
  {
 -ERR(Trying to destroy a NULL context pointer!);
 +ERR(Trying to destroy a NULL context pointer!\n);
 return;
  }

 @@ -256,12 +256,6 @@
return EINA_FALSE;
MAGIC_CHECK_END();

 -   if ((!surf) || (!ns))
 - {
 -ERR(Invalid input parameters!);
 -return EINA_FALSE;
 - }
 -
return
 (Eina_Bool)evas_gl-evas-engine.func-gl_native_surface_get(evas_gl-evas-engine.data.output,
 surf-data, ns);
  }


 Modified: trunk/evas/src/modules/engines/gl_x11/evas_engine.c
 ===
 --- trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
 10:54:14 UTC (rev 70623)
 +++ trunk/evas/src/modules/engines/gl_x11/evas_engine.c 2012-05-02
 11:07:29 UTC (rev 70624)
 @@ -41,26 +41,17 @@
int w, h;
int vsync;

 -   // GL Surface Capability
 -   struct {
 -int rgb_fmt;
 -int rgba_fmt;
 +   // Shader used for Evas_GL_Direct Optimization
 +   GLuint   df_program;
 +   GLuint   df_vtx_shader;
 +   GLuint   df_fgmt_shader;
 +   GLuint   df_col_attrib;
 +   GLuint   df_pos_attrib;

 -int depth_8;
 -int depth_16;
 -int depth_24;
 -int depth_32;
 +   GLfloat  df_clear_color[4];
 +   GLfloat  df_depth_value;

 -int stencil_1;
 -int stencil_2;
 -int stencil_4;
 -int stencil_8;
 -int stencil_16;
 -
 -int depth_24_stencil_8;
 -   } gl_cap;
 -
 -   int gl_cap_initted;
 +   int  df_initialized;
  };

  struct _Render_Engine_GL_Surface
 @@ -73,7 +64,7 @@

int  direct_fb_opt;

 -   // Render target Texture/Buffers
 +   // Render target texture/buffers
GLuint   rt_tex;
GLintrt_internal_fmt;
GLenum

Re: [E-devel] [Patch] Add override gl apis for osmesa

2012-02-23 Thread Sung W. Park

Silly mistake on my part.  Thanks for the report.
In SVN!

Thanks!
-Sung


2012/2/24 우승수 om101@samsung.com


 Dear All,

 When an application use glBindFramebuffer or glBindRenderbuffer via
 evas_gl after loding libosmesa.so,
 it shows segment fault.

 Because glBindFramebuffer and glBindRenderbuffer are not overrided.
 So, I fixed it.

 Thanks,
 Seungsoo



 --
 Virtualization  Cloud Management Using Capacity Planning
 Cloud computing makes use of virtualization - but cloud computing
 also focuses on allowing computing to be delivered as a service.
 http://www.accelacomm.com/jaw/sfnl/114/51521223/
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel] Access

2011-12-21 Thread Sung W. Park

that's right!  better watch out for the fatality move~  ;-)

2011/12/21 ChunEon Park her...@naver.com

 Here comes new Mortal Kombat character!
 
 -Regards, Hermet-

 -Original Message-
 From: Sung W. Parklt;sung...@gmail.comgt;
 To: Enlightenment developer list
 lt;enlightenment-devel@lists.sourceforge.netgt;
 Cc:
 Sent: 11-12-20(화) 16:08:20
 Subject: Re: [E-devel] [E-Devel] Access
 hi all,
 sorry this took so long. i got slammed with some bugs that i had to fix
 before I
 left for Hong Kong for a week to attend a conference. Now I'm back finally
 and
 ready to commit some code!
 I'm attaching the necessary files.
 looking forward working together with you guys~!
 by the way, that's a wig in the picture ;)
 cheers,
 Sung
 On Mon, Dec 5, 2011 at 11:37 AM, Sung W. Park lt;sung...@gmail.comgt;
 wrote:
  Hi all,
 
  I've been working on Evas GL for some time now and I would like to
 request
  a
  commit access.
 
  I've been solely working on Evas_GL, elm_glview up until now and pretty
  much,
  Raster has been the only person reviewing my code.
 
  I'm at a point where having a commit access would make things a lot
 easier
  for
  me and also benefit the community as well.
 
  Here's what I've worked on and what I plan to work on.
 
  - I've proposed the Evas_GL APIs as a way to do GL rendering in Evas and
  have
  implemented the APIs for the runtime and the GL backend, both of which
 have
  been upstreamed.
  - I've also implemented an elementary widget called ELM GLView to make GL
  rendring even simpler using elementary. Again, this has been applied
  upstream
  as well.
  - I have also worked on two key optimizations, both of which are
  streamlined
  for review. One is called the GL Fastpath where I've implemented the
 state
  tracking mechanism for GL drivers that have expensive context swtiches.
  Also,
  I've implmented a direct rendering mechanism where if you turn on the
  optimization hint on, it will render directly onto the Evas' X window
  whenever
  possible. (They still need to be refined but it's a good start in my
  opinion)
  - I also have the Evas_GL software backend implemented but I haven't been
  able to submit a patch for it yet due to other pending patches.
  - I still need to write more test code and settle on the APIs once
 they've
  been tested more by the community.
  - Eventually, I would like to work more on Evas as well when the
  refactoring
  takes place as I recognize along with Raster and others that it's about
  time
  for anoter round of refactoring/rearchitecting the code.
 
  Let me know if you have questions or concerns.
 
  cheers,
  Sung
 

 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join

 http://p.sf.net/sfu/intel-appdev___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster IN trunk/devs: . sung

2011-12-21 Thread Sung W. Park

does that mean I'm Spiderman?  ;-)

On Wed, Dec 21, 2011 at 7:24 PM, Daniel Juyung Seo seojuyu...@gmail.comwrote:

 Congratulations!
 With great power comes great responsibility.

 Daniel Juyung Seo (SeoZ)

 On Wed, Dec 21, 2011 at 6:30 PM, Enlightenment SVN
 no-re...@enlightenment.org wrote:
  Log:
  sung++!
 
 
 
  Author:   raster
  Date: 2011-12-21 01:30:04 -0800 (Wed, 21 Dec 2011)
  New Revision: 66435
  Trac: http://trac.enlightenment.org/e/changeset/66435
 
  Added:
   trunk/devs/sung/ trunk/devs/sung/icon-big.png
 trunk/devs/sung/icon-med.png trunk/devs/sung/icon-sml.png
 trunk/devs/sung/id_rsa.pub trunk/devs/sung/info.txt
 
 
  Property changes on: trunk/devs/sung/icon-big.png
  ___
  Added: svn:mime-type
+ application/octet-stream
 
 
  Property changes on: trunk/devs/sung/icon-med.png
  ___
  Added: svn:mime-type
+ application/octet-stream
 
 
  Property changes on: trunk/devs/sung/icon-sml.png
  ___
  Added: svn:mime-type
+ application/octet-stream
 
 
 
 --
  Write once. Port to many.
  Get the SDK and tools to simplify cross-platform app development. Create
  new or port existing apps to sell to consumers worldwide. Explore the
  Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
  http://p.sf.net/sfu/intel-appdev
  ___
  enlightenment-svn mailing list
  enlightenment-...@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/enlightenment-svn


 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create
 new or port existing apps to sell to consumers worldwide. Explore the
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [E-Devel] Access

2011-12-04 Thread Sung W. Park

Hi all,

I've been working on Evas GL for some time now and I would like to request a
commit access.

I've been solely working on Evas_GL, elm_glview up until now and pretty much,
Raster has been the only person reviewing my code.

I'm at a point where having a commit access would make things a lot easier for
me and also benefit the community as well.

Here's what I've worked on and what I plan to work on.

- I've proposed the Evas_GL APIs as a way to do GL rendering in Evas and have
implemented the APIs for the runtime and the GL backend, both of which have
been upstreamed.
- I've also implemented an elementary widget called ELM GLView to make GL
rendring even simpler using elementary. Again, this has been applied upstream
as well.
- I have also worked on two key optimizations, both of which are streamlined
for review. One is called the GL Fastpath where I've implemented the state
tracking mechanism for GL drivers that have expensive context swtiches. Also,
I've implmented a direct rendering mechanism where if you turn on the
optimization hint on, it will render directly onto the Evas' X window whenever
possible.  (They still need to be refined but it's a good start in my opinion)
- I also have the Evas_GL software backend implemented but I haven't been
able to submit a patch for it yet due to other pending patches.
- I still need to write more test code and settle on the APIs once they've
been tested more by the community.
- Eventually, I would like to work more on Evas as well when the refactoring
takes place as I recognize along with Raster and others that it's about time
for anoter round of refactoring/rearchitecting the code.

Let me know if you have questions or concerns.

cheers,
Sung

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel] Access

2011-12-04 Thread Sung W. Park

Awesome!  I look forward to working with you guys more closely as a
developer.  Thanks!

cheers,
Sung
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath

2011-11-07 Thread Sung W. Park

Hi Carsten,

That's really weird.  I've tested elementary_test before I submitted the
patch.
I'm wondering if there were changes that I made that would require
elementary recompile...  i can't think of one at the moment.

Just curious, are you using evas with NEWGL enabled?  If that's the case, it
explains the breakage.  My understanding was that NEWGL was broken and it
wasn't turned on by default so I didn't bother with it for now.

I'll try to track down the issue.

cheers,
Sung


On Sun, Nov 6, 2011 at 2:48 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 26 Oct 2011 14:08:47 +0900 Sung W. Park sung...@gmail.com
 said:

  Hi all,
 
  I'm attaching a patch for the initial version of the GL Fastpath
 addition to
  evas gl backend.
 
  Working on different mobile devices, we've noticed that the cost of
 context
  switch (MakeCurrent) in GL can be very expensive depending on the driver
  implementation.  To minimize the poorly written driver's context switch
  overhead, I've implemented a state tracking layer on top of the driver
  implemented GL.
 
  Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages
 its
  own state changes.  Internally, only one real GL context is created and
  logical contexts are created every time a user requests context creation.
  The logical contexts keep track of its states and sets only the necessary
  states (the ones that are different than the current ones)
  when there is a MakeCurrent request.  The real MakeCurrent gets called
 when
  there is a Surface/Window change request.
 
  The GL library is dlopened and all the APIs are dlsym'ed and wrapped
  accordingly.  All the GL functions are in evas_gl_core.{h,c}.
 
  Here's a very simply flow of the code.
 - all the APIs are exported as function pointers (*glsym_glBegin),
   (*glsm_eglCreatContext), and etc.
 - all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
   _sym_eglCreateContext, and etc.
 - all the fastpath APIs are implmemnted as fpgl_glBegin,
   fpgl_eglCreateContext, and etc.
 - if faspath is seletected, the exported APIs are set accordingly
   ie. glsym_glBegin = fpgl_glBegin;
 - default mode is the regular gl symbols are directly set.
   ie. glsym_glBegin = _sym_glBegin;
 
  I have an Environment variable where you can set it to three different
 Modes
 
  EVAS_GL_FASTPATH = 0// Default mode. Regular GL symbols are directly
  loaded EVAS_GL_FASTPATH = 1// Fastpath mode. Takes the path described
  above. EVAS_GL_FASTPATH = 2// Wrapped mode.  All the regular GL
 functions
  are wrapped once.  This can be used for various purposes
 
  Since all the GL symbols are now loaded in this library, I took out all
  the gl symbol loading parts in the evas gl backend as you'll see in the
 patch.
  The changes to the engine and the backend itself is pretty minor.
 
  There are still some known issues to hammer out but I thought we're at a
 good
  place for an initial version so that my source doesn't diverge too much.
 
  Known Issues and To Do's
  * Current GL Fastpath version doesn't support multiple threads.  Instead
 of
having one global real context, I would need to do it for each thread.
 I'll
get on this soon.

 this is.. unfortunately... important :( not currently, but in future it
 will be.

  * Issues running Evas GL on certain conditions.  When running the
 elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND
  mode, everything works fine. BUT, when you run the ELMGLView test in
 ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.

 smells of a context tracking bug to me.

  * Resource protection code.  This actually applies to Evas GL code in
 general
as well. Since all the resources are shared among all the contexts
 that get
created, I would like to eventually have a resource protecting
 mechanism
  that prevents access to resources outside of its context unless
 specifically
specified.

 how do you know which context a resource belongs to? eg a texture. afre you
 going to forbid 2 ctx's to set the same texture id as src texture for ops?
 sounds silly.

  I'm attaching three files
 - evas_gl_core.h, evas_gl_core.c, fastpath.patch
 
  To get the code running...
 - copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
 - apply the fastpath.patch
 - compile/install evas
 - to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
 
 
  Let me know if you have questions or comments.

 big problem. it breaks the gl engine as-is:

  2:46PM ~  ELM_ENGINE=gl elementary_test
 Initializing OpenGL APIs...
 API OPT: 0 Default API path enabled...
 ERR16397:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
 glsym_glXChooseFBConfig returned no configs ERR16397:evas-gl_x11
 evas_x_main.c:802 eng_best_visual_get() glsym_glXChooseFBConfig returned no
 configs ERR16397

Re: [E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

2011-10-28 Thread Sung W. Park

wow, that was the fastest review/commit thus far! ;)  thanks!!

On Fri, Oct 28, 2011 at 8:08 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 28 Oct 2011 14:10:14 +0900 Sung W. Park sung...@gmail.com
 said:

 this one is in svn! approved. good! thanks muchly! :)

  Hi all,
 
  I'm submitting a patch that changes the color format for Evas GL.
 
  When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8
 and
  etc but it was misleading for some people.  It was more of a filler since
  I couldn't decide on
  a name.  I'm finally changing it to make it more clear.
 
  typedef enum _Evas_GL_Color_Format
  {
  EVAS_GL_RGB_888 = 0,  // 8 bits per channel
  EVAS_GL_RGBA_ = 1
  } Evas_GL_Color_Format;
 
  typedef enum _Evas_GL_Depth_Bits
  {
  EVAS_GL_DEPTH_NONE   = 0,
  EVAS_GL_DEPTH_BIT_8  = 1,
  EVAS_GL_DEPTH_BIT_16 = 2,
  EVAS_GL_DEPTH_BIT_24 = 3,
  EVAS_GL_DEPTH_BIT_32 = 4,
  } Evas_GL_Depth_Bits;
 
  typedef enum _Evas_GL_Stencil_Bits
  {
  EVAS_GL_STENCIL_NONE   = 0,
  EVAS_GL_STENCIL_BIT_1  = 1,
  EVAS_GL_STENCIL_BIT_2  = 2,
  EVAS_GL_STENCIL_BIT_4  = 3,
  EVAS_GL_STENCIL_BIT_8  = 4,
  EVAS_GL_STENCIL_BIT_16 = 5,
  } Evas_GL_Stencil_Bits;
 
  This will deal with backward compatibility issues as long as we keep the
  ordering and the number same.
 
  I'm also including an Elmentary patch for elm_glview.c that changes the
 format
  accordingly.
 
  Two patches:
 evas_gl_format_change.path// For Evas
 elmglview_evas_gl_format_change.patch   // For Elementary
 
 
  Thanks a bunch.
 
  cheers,
  Sung


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [E-Devel][Patch] Evas GL Color Format Enum change (and ElmGLview changes accordingly)

2011-10-27 Thread Sung W. Park

Hi all,

I'm submitting a patch that changes the color format for Evas GL.

When I first wrote Evas_GL, I just had EVAS_GL_RGB_8 and EVAS_GL_RGBA_8 and etc
but it was misleading for some people.  It was more of a filler since
I couldn't decide on
a name.  I'm finally changing it to make it more clear.

typedef enum _Evas_GL_Color_Format
{
EVAS_GL_RGB_888 = 0,  // 8 bits per channel
EVAS_GL_RGBA_ = 1
} Evas_GL_Color_Format;

typedef enum _Evas_GL_Depth_Bits
{
EVAS_GL_DEPTH_NONE   = 0,
EVAS_GL_DEPTH_BIT_8  = 1,
EVAS_GL_DEPTH_BIT_16 = 2,
EVAS_GL_DEPTH_BIT_24 = 3,
EVAS_GL_DEPTH_BIT_32 = 4,
} Evas_GL_Depth_Bits;

typedef enum _Evas_GL_Stencil_Bits
{
EVAS_GL_STENCIL_NONE   = 0,
EVAS_GL_STENCIL_BIT_1  = 1,
EVAS_GL_STENCIL_BIT_2  = 2,
EVAS_GL_STENCIL_BIT_4  = 3,
EVAS_GL_STENCIL_BIT_8  = 4,
EVAS_GL_STENCIL_BIT_16 = 5,
} Evas_GL_Stencil_Bits;

This will deal with backward compatibility issues as long as we keep the
ordering and the number same.

I'm also including an Elmentary patch for elm_glview.c that changes the format
accordingly.

Two patches:
   evas_gl_format_change.path// For Evas
   elmglview_evas_gl_format_change.patch   // For Elementary


Thanks a bunch.

cheers,
Sung
Index: src/lib/Evas_GL.h
===
--- src/lib/Evas_GL.h	(revision 64471)
+++ src/lib/Evas_GL.h	(working copy)
@@ -18,29 +18,27 @@
 
 typedef enum _Evas_GL_Color_Format
 {
-EVAS_GL_RGB_8,  // 8 bits per channel
-EVAS_GL_RGBA_8,
-EVAS_GL_RGB_32, // 32-bits per channel
-EVAS_GL_RGBA_32,
+EVAS_GL_RGB_888   = 0,
+EVAS_GL_RGBA_ = 1
 } Evas_GL_Color_Format;
 
 typedef enum _Evas_GL_Depth_Bits
 {
-EVAS_GL_DEPTH_BIT_8,
-EVAS_GL_DEPTH_BIT_16,
-EVAS_GL_DEPTH_BIT_24,
-EVAS_GL_DEPTH_BIT_32,
-EVAS_GL_DEPTH_NONE
+EVAS_GL_DEPTH_NONE   = 0,
+EVAS_GL_DEPTH_BIT_8  = 1,
+EVAS_GL_DEPTH_BIT_16 = 2,
+EVAS_GL_DEPTH_BIT_24 = 3,
+EVAS_GL_DEPTH_BIT_32 = 4,
 } Evas_GL_Depth_Bits;
 
 typedef enum _Evas_GL_Stencil_Bits
 {
-EVAS_GL_STENCIL_BIT_1,
-EVAS_GL_STENCIL_BIT_2,
-EVAS_GL_STENCIL_BIT_4,
-EVAS_GL_STENCIL_BIT_8,
-EVAS_GL_STENCIL_BIT_16,
-EVAS_GL_STENCIL_NONE
+EVAS_GL_STENCIL_NONE   = 0,
+EVAS_GL_STENCIL_BIT_1  = 1,
+EVAS_GL_STENCIL_BIT_2  = 2,
+EVAS_GL_STENCIL_BIT_4  = 3,
+EVAS_GL_STENCIL_BIT_8  = 4,
+EVAS_GL_STENCIL_BIT_16 = 5,
 } Evas_GL_Stencil_Bits;
 
 struct _Evas_GL_Config
@@ -98,7 +96,7 @@
// config for the surface for evas_gl
Evas_GL_Config config =
  {
-EVAS_GL_RGBA_8,
+EVAS_GL_RGBA_,
 EVAS_GL_DEPTH_NONE,
 EVAS_GL_STENCIL_NONE
  };
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 64471)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -2778,20 +2778,14 @@
// Also initialize pixel format here as well...
switch(cfg-color_format)
  {
-  case EVAS_GL_RGB_8:
+  case EVAS_GL_RGB_888:
  sfc-rt_fmt  = GL_RGB;
  sfc-rt_internal_fmt = GL_RGB;
  break;
-  case EVAS_GL_RGBA_8:
+  case EVAS_GL_RGBA_:
  sfc-rt_fmt  = GL_RGBA;
  sfc-rt_internal_fmt = GL_RGBA;
  break;
-  case EVAS_GL_RGB_32:
- // Only supported on some hw
- // Fill it in later...
-  case EVAS_GL_RGBA_32:
- // Only supported on some hw
- // Fill it in later...
   default:
  ERR(Invalid Color Format!);
  return 0;
Index: src/lib/elm_glview.c
===
--- src/lib/elm_glview.c	(revision 64471)
+++ src/lib/elm_glview.c	(working copy)
@@ -219,7 +219,7 @@
Evas_Object *obj;
Evas *e;
Widget_Data *wd;
-   Evas_GL_Config cfg = { EVAS_GL_RGB_8,
+   Evas_GL_Config cfg = { EVAS_GL_RGB_888,
   EVAS_GL_DEPTH_NONE,
   EVAS_GL_STENCIL_NONE };
 
@@ -295,14 +295,14 @@
 {
ELM_CHECK_WIDTYPE(obj, widtype) EINA_FALSE;
Widget_Data *wd = elm_widget_data_get(obj);
-   Evas_GL_Config cfg = { EVAS_GL_RGBA_8,
+   Evas_GL_Config cfg = { EVAS_GL_RGBA_,
   EVAS_GL_DEPTH_NONE,
   EVAS_GL_STENCIL_NONE };
if (!wd) return EINA_FALSE;
 
// Set the configs
if (mode  ELM_GLVIEW_ALPHA)
- cfg.color_format = EVAS_GL_RGBA_8;
+ cfg.color_format = EVAS_GL_RGBA_;
 
if (mode  ELM_GLVIEW_DEPTH)
  cfg.depth_bits = EVAS_GL_DEPTH_BIT_24;
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications,

[E-devel] [E-Devel][Patch] Eina TLS

2011-10-12 Thread Sung W. Park

Hi all,

I was in need of using thread local storage for some of the EvasGL stuff that
I'm currently working on. I've noticed that Eina doesn't have thread local
storage functions.  It would be best to simply use load-time TLS by using
__thread in Linux or __declspec(thread) in Windows in front of variables but
these two are not supported in all platforms that EFL supports.

You can check out what's supported in different platforms at this link below:

https://chtekk.longitekk.com/index.php?/archives/70-TLS-and-shared-library-initialization.html

So, I've decdied to add Eina APIs for run-time TLS support.

Here's an initial set of APIs that I've implemented.

static inline Eina_Bool eina_tls_new(Eina_TLS *key);
static inline void eina_tls_free(Eina_TLS key);
static inline void *eina_tls_get(Eina_TLS key);
static inline Eina_Bool eina_tls_set(Eina_TLS key, const void *data);

I didn't add destructor function pointer in eina_tls_new even though it's
supported in pthreads because they're not supported in windows.

I've tested the posix implmentation but I haven't been able to test the Windows
version.  If someone can review/test the code, that would be very helpful.

Let me know what you think.

cheers,
Sung
Index: src/include/eina_inline_lock_void.x
===
--- src/include/eina_inline_lock_void.x	(revision 64010)
+++ src/include/eina_inline_lock_void.x	(working copy)
@@ -215,6 +215,30 @@
return EINA_LOCK_FAIL;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   return EINA_FALSE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return NULL;
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   return EINA_FALSE;
+}
+
+
 /**
  * @}
  */
Index: src/include/eina_inline_lock_win32.x
===
--- src/include/eina_inline_lock_win32.x	(revision 64010)
+++ src/include/eina_inline_lock_win32.x	(working copy)
@@ -433,4 +433,32 @@
return EINA_LOCK_SUCCEED;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (TlsAlloc() == TLS_OUT_OF_INDEXES)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+   TlsFree(key);
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return (void*)TlsGetValue(key);
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   if (TlsSetValue(key, (LPVOID)data) == 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
 #endif
Index: src/include/eina_lock.h
===
--- src/include/eina_lock.h	(revision 64010)
+++ src/include/eina_lock.h	(working copy)
@@ -76,6 +76,12 @@
 static inline Eina_Lock_Result eina_rwlock_take_write(Eina_RWLock *mutex);
 static inline Eina_Lock_Result eina_rwlock_release(Eina_RWLock *mutex);
 
+static inline Eina_Bool eina_tls_new(Eina_TLS *key);
+static inline void eina_tls_free(Eina_TLS key);
+static inline void *eina_tls_get(Eina_TLS key);
+static inline Eina_Bool eina_tls_set(Eina_TLS key, const void *data);
+
+
 #ifdef EINA_HAVE_DEBUG_THREADS
 # define EINA_MAIN_LOOP_CHECK_RETURN_VAL(val)\
   do {	\
Index: src/include/eina_inline_lock_wince.x
===
--- src/include/eina_inline_lock_wince.x	(revision 64010)
+++ src/include/eina_inline_lock_wince.x	(working copy)
@@ -23,8 +23,9 @@
 
 EAPI extern Eina_Bool _threads_activated;
 
-typedef HANDLE Eina_Lock;
+typedef HANDLEEina_Lock;
 typedef Eina_Lock Eina_RWLock;
+typedef DWORD Eina_TLS;
 
 static inline Eina_Bool
 eina_lock_new(Eina_Lock *mutex)
@@ -144,4 +145,34 @@
return eina_lock_release(mutex);
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (TlsAlloc() == TLS_OUT_OF_INDEXES)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+static inline void 
+eina_tls_free(Eina_TLS key)
+{
+   TlsFree(key);
+}
+
+static inline void *
+eina_tls_get(Eina_TLS key)
+{
+   return (void*)TlsGetValue(key);
+}
+
+static inline Eina_Bool 
+eina_tls_set(Eina_TLS key, const void *data)
+{
+   if (TlsSetValue(key, (LPVOID)data) == 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+
+
+
 #endif
Index: src/include/eina_inline_lock_posix.x
===
--- src/include/eina_inline_lock_posix.x	(revision 64010)
+++ src/include/eina_inline_lock_posix.x	(working copy)
@@ -44,6 +44,7 @@
 typedef struct _Eina_Lock Eina_Lock;
 typedef struct _Eina_RWLock Eina_RWLock;
 typedef struct _Eina_Condition Eina_Condition;
+typedef pthread_key_t Eina_TLS;
 
 struct _Eina_Lock
 {
@@ -477,4 +478,32 @@
return EINA_LOCK_SUCCEED;
 }
 
+static inline Eina_Bool 
+eina_tls_new(Eina_TLS *key)
+{
+   if (pthread_key_create(key, NULL) != 0)
+  return EINA_FALSE;
+   return EINA_TRUE;
+}
+

[E-devel] [Review] [Patch] Evas_GL bug fixes/updates

2011-08-22 Thread Sung W. Park

Hi all,

I've fixed some minor issues that I've been pushing off for later.

The patch does the following:

1. Evas_GL and Evas had an issue where the viewport parameters were
being reset in the wrong context. Previously, this issue was temporarily
patched by flushing evas' pipeline and setting
evas_gl_common_context_use(NULL) in EvasGL's
make current. I know, it was pretty hacky. It turns out that in evas_engine,
there was a code evas_gl_common_context_resize(NULL) without doing
eng_window_use() first.  So i've added that part and problem went was
resolved properly. :-)

2. Naturally, I've taken out the temporary patch from 1.

3. I've added code that took care of glBindFramebuffer(..., fbo) where the
fbo had to be saved and restored in case the user wanted to use his own fbo.
Also, I've had to take care of the case when fbo is 0 since 0 need to point
to evas_gl surface.

4. I've updated make_current a little as well.

It's not that big of a patch.  let me know what you guys think.

cheers,
Sung


evas_gl_update.patch
Description: Binary data
--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch] ELM GLView updates

2011-06-20 Thread Sung W. Park

cool, thanks!

well hopefully we'll have the software-backend running GL stuff as well
soon.
I think we can do but it'll take time for me to get to it, unless
someones gets on
it before I do.

I hear ya on the bastard son.  we hate it but sometimes it happens aswe try
to
bring two together.  Hopefully we won't see many more of those.

anyway, looking forward to more comments and suggestions on how we can make
the GL stuff better on EFL.

cheers,
Sung

yeah, i hear ya on the callbacks here, especially the resize.

On Mon, Jun 20, 2011 at 7:57 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 20 Jun 2011 11:18:56 +0900 Sung W. Park sung...@gmail.com
 said:

 in svn as it pretty much fixes things. comments here;

 1. not totally into the idea of setting engine explicitly before u create
 the
 window :( if its not a gl engine this test cant really work and that config
 is
 controls system-wide for gl apps atm. this SHOULD work without the gl
 engine
 via a software mesa fallback so setting the engine kind of will hide that
 fact
 that that isnt done yet :)
 2. thought i really don't like the resize callback i'll let it pass as this
 is
 some kind of bastard son of both efl and opengl and there isn't really a
 pure
 one true way and there is very little you can do to make both sides
 totally
 happy as there is a fundamental design philosophy difference between them
 in
 certain areas :(

  Hi all,
 
  Upon reviewing the elm_glview, I've realized a few issues and mistakes
 that
  i've made originally so I've made some changes/ updates to elm_glview
 
  1.)  GL Resource Deletion in ELM_GLView
 
  In order to delete GL resources, the current approach simply registered a
  delete callback to the GLView object and handled resource deletion there.
  Unfortunately, using the delete callback did not guarantee the glview
  context to be
  current.  In order to guarantee that the current context was the glview
  context, the make_current call needs to be called explicitly.  Since we
 were
  hiding all the
  make current details in elm_glview, i've decided to add an API that
 registers
  a delete callback function. I know that this may seem redundant since
  there is already
  a delete callback that you can register with glview objects.
  Unfortunately, this is the
  only option that we have apart from exposing make_current, which is
  something that
  went again what we are trying to do with elm_glview.
 
  Since adding delete callback alone seemed a little out of place, i've
  taken the liberty
  to add other callback functions to make it seem consistent.
 
  void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func);
  void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func);
  void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func);
 
  resize callback can be controversial as well but I want to argue that
  adding this callback
  makes the render function a lot cleaner.  To handle resize
  differently, the user in
  render function needs to manually compare and see if the size has
 changed, and
  then handle the cases.  Doing all of this internally once makes the
  developers life
  a lot easier in my opinion.
 
  these callback functions do make the render function a lot cleaner.
  You can check
  out the updated test_glview.c or newly added test_glview_simple.
 
  2.) Minor bug fixes/changes
 
  elm_glview_scale_policy_set() was supposed to be
 elm_glview_resize_policy_set
  () but it somehow evaded our reviews.  That has been fixed.
 
  Also, in _glview_resize, after updating the surface, it was explicitly
  calling the
  render function.  It is actually unnecessary here and calling it here
  will cause
  problems if resize gets called before everything else is setup
  properly.  So that has
  been commented out.
 
  3.) test_glview  test_glview_simple
 
  elementary_test case for glview has been updated to reflect the api
 changes.
  when you run the elmentary_test, you need to make sure that you set
  ELM_ENGINE=gl as glview currently only runs on gl backend.
 
  test_glview runs the gears example.  For testing purposes I've included a
  simple glview test case that renders a triangle and changing background
 color.
 
  4.) Attached Files: elm_glview_update.patch, test_glview_simple.c
- copy test_glview_simple.c to elementary/src/bin directory
- apply patch using patch -p0 elm_glview_update.patch
- Do make, make install
- run by
   %ELM_ENGINE=gl elmentary_test
 
 
  Comments and suggestions would be much appreciated.
 
  thanks a bunch!
  Sung


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant

[E-devel] [Patch] ELM GLView updates

2011-06-19 Thread Sung W. Park

Hi all,

Upon reviewing the elm_glview, I've realized a few issues and mistakes that i've
made originally so I've made some changes/ updates to elm_glview

1.)  GL Resource Deletion in ELM_GLView

In order to delete GL resources, the current approach simply registered a
delete callback to the GLView object and handled resource deletion there.
Unfortunately, using the delete callback did not guarantee the glview
context to be
current.  In order to guarantee that the current context was the glview context,
the make_current call needs to be called explicitly.  Since we were
hiding all the
make current details in elm_glview, i've decided to add an API that registers a
delete callback function. I know that this may seem redundant since
there is already
a delete callback that you can register with glview objects.
Unfortunately, this is the
only option that we have apart from exposing make_current, which is
something that
went again what we are trying to do with elm_glview.

Since adding delete callback alone seemed a little out of place, i've
taken the liberty
to add other callback functions to make it seem consistent.

void elm_glview_init_func_set(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_del_func_set(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_resize_func_set(Evas_Object *obj, Elm_GLView_Func func);

resize callback can be controversial as well but I want to argue that
adding this callback
makes the render function a lot cleaner.  To handle resize
differently, the user in
render function needs to manually compare and see if the size has changed, and
then handle the cases.  Doing all of this internally once makes the
developers life
a lot easier in my opinion.

these callback functions do make the render function a lot cleaner.
You can check
out the updated test_glview.c or newly added test_glview_simple.

2.) Minor bug fixes/changes

elm_glview_scale_policy_set() was supposed to be elm_glview_resize_policy_set()
but it somehow evaded our reviews.  That has been fixed.

Also, in _glview_resize, after updating the surface, it was explicitly
calling the
render function.  It is actually unnecessary here and calling it here
will cause
problems if resize gets called before everything else is setup
properly.  So that has
been commented out.

3.) test_glview  test_glview_simple

elementary_test case for glview has been updated to reflect the api changes.
when you run the elmentary_test, you need to make sure that you set
ELM_ENGINE=gl as glview currently only runs on gl backend.

test_glview runs the gears example.  For testing purposes I've included a simple
glview test case that renders a triangle and changing background color.

4.) Attached Files: elm_glview_update.patch, test_glview_simple.c
  - copy test_glview_simple.c to elementary/src/bin directory
  - apply patch using patch -p0 elm_glview_update.patch
  - Do make, make install
  - run by
 %ELM_ENGINE=gl elmentary_test


Comments and suggestions would be much appreciated.

thanks a bunch!
Sung


elm_glview_update.patch
Description: Binary data
#include Elementary.h
#ifdef HAVE_CONFIG_H
# include elementary_config.h
#endif
#ifndef ELM_LIB_QUICKLAUNCH

typedef struct _GLData GLData;

// GL related data here..
struct _GLData
{
   Evas_GL_API *glapi;
   GLuint   program;
   GLuint   vtx_shader;
   GLuint   fgmt_shader;
   GLuint   vbo;
   int  initialized : 1;
};


static float red = 1.0;

////
static GLuint
load_shader( GLData *gld, GLenum type, const char *shader_src )
{
   Evas_GL_API *gl = gld-glapi;
   GLuint shader;
   GLint compiled;

   // Create the shader object
   shader = gl-glCreateShader(type);
   if (shader==0)
  return 0;

   // Load/Compile shader source
   gl-glShaderSource(shader, 1, shader_src, NULL);
   gl-glCompileShader(shader);
   gl-glGetShaderiv(shader, GL_COMPILE_STATUS, compiled);

   if (!compiled) 
 {
GLint info_len = 0;
gl-glGetShaderiv(shader, GL_INFO_LOG_LENGTH, info_len);
if (info_len  1)
  {
 char* info_log = malloc(sizeof(char) * info_len);

 gl-glGetShaderInfoLog(shader, info_len, NULL, info_log);
 printf(Error compiling shader:\n%s\n, info_log );
 free(info_log);
  }
gl-glDeleteShader(shader);
return 0;
 }

   return shader;
}

// Initialize the shader and program object
static int 
init_shaders(GLData *gld)
{
   Evas_GL_API *gl = gld-glapi;
   GLbyte vShaderStr[] =  
  attribute vec4 vPosition;\n
  void main()  \n
  {\n
 gl_Position = vPosition;  \n
  }\n;

   GLbyte fShaderStr[] =  
  precision mediump float;\n\
  void main()  \n
  {\n
gl_FragColor = vec4 ( 1.0, 0.0, 0.0, 1.0 );\n
  }

Re: [E-devel] [RFC] ELM GLView

2011-06-06 Thread Sung W. Park

awesome!   I guess we now have to make sure this thing is stable.  =)

On Fri, Jun 3, 2011 at 4:09 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Thu, 19 May 2011 16:37:11 +0900 Sung W. Park sung...@gmail.com
 said:

 just put it in svn now. yay! :) thanks! :)

  Thanks for your comments.
 
  Ok, I've added a focus_hook so it now handles events properly.  Now
  the elmglviewgears
  handles key events and mouse events.  You can rotate it using
  Left,Right,Up,Down Arrows
  or use the mouse and drag it.  It doesn't actually have a real
  trackball feature
  implemented so you will notice it not rotating it properly if you
  rotate it too much.
 
  I've dropped the elm_glview_z_get function.  I didn't think it was
  necessary for now.
  maybe we can add it later.
 
  Also, the gl_func_call api was for internal testing purpose and it was
  commented out
  in the patch but i've removed them completely in this patch.
 
  Also, I've made some changes with the API.   It has been brought to my
  attention that there is a performance issue with the way the current APIs
 are
  implemented. Currently, the render function was registered using the
 
  evas_object_image_pixels_get_callback_set
 
  This is so that it doesn't trigger GL rendering when the image object
  isn't visible.
  Unfortunately, it causes and extra make_current to be called during
  the rendering
  life cycle of evas.
 
  Evas Render... - (context switch) - EvasGL Renders - (context_switch)
 -
  Evas Finishes rendering
 
  The context switch is quite expensive in the hw driver that i'm using
  so it actually
  lowers the performance quite a bit.
 
  SO, after discussing it with a few people, we've decided to give an
  option to the user
  to choose the rendering policy.  If you choose to have render function
  render all the time,
  it avoids one extra context switch.
 
  EvasGL Renders - (context_switch) - Evas Renders
 
  Hence the render policy of RENDER_POLICY_ON_DEMAND vs.
 RENDER_POLICY_ALWAYS.
 
  I've also changed the name elm_glview_display_func to
  elm_glview_render_func
 
  Here's the latest set of elm_glview APIs...
  __
 
  typedef enum _Elm_GLView_Resize_Policy
{
   ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
   ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
} Elm_GLView_Resize_Policy;
 
  typedef enum _Elm_GLView_Render_Policy
{
   ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
   ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
} Elm_GLView_Render_Policy;
 
 
  Evas_Object*elm_glview_add(Evas_Object *parent);
  void elm_glview_size_set(Evas_Object *obj, Evas_Coord
  width, Evas_Coord height);
  void elm_glview_size_get(Evas_Object *obj, Evas_Coord
  *width, Evas_Coord *height);
  Evas_GL_API  *elm_glview_gl_api_get(Evas_Object *obj);
  Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
  Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
  Elm_GLView_Resize_Policy policy);
  Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
  Elm_GLView_Render_Policy policy);
  void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func
  func); void elm_glview_changed_set(Evas_Object *obj);
  __
 
  I'm including the updated elm_glview patch/files and the updated
  elmglviewgears.
 
  Let me know if you have questions/comments.
 
  cheers,
  Sung
 
 
  On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler ras...@rasterman.com
  wrote:
  
   On Fri, 13 May 2011 00:00:50 +0900 Sung W. Park sung...@gmail.com
 said:
  
   ok. missing the focus hook thing u'd need if u want key events to
 work...
   display_func - render_func_set() probably better. z_get probably can
 be
   skipped if really too much of a pita.
  
   whats the gl_func_call api for.. why pass the func - u already set it?
 could
   set it then call a manual render.. if that's needed. is it really
 needed?
   curious.  :)
  
Hi all,
   
As you all know, I've been working on adding GL rendering features to
Evas and we now have an early working version of Evas_GL in the svn.
   
Since then, there's been a request from people around me for an
elementary widget that
allows simple GL rendering.  Since Evas_GL can be seen as a low level
 API
it made sense to have a user friendly layer that allows GL rendering.
  I
thought it
went well with the EFL philosophy.  Take away some control but make
 it
easy to use for the users as you go up the layers from
 Evas-Ecore-ELM-
etc.
   
So, I've decided to take a crack at elm_glview.  By the way, this is
my first time writing
an elementary widget so I KNOW I've missed a lot that i need to
 handle.
 Also, I'm aware of the fact thatI need to handle input events. I'll
 need
to figure that out
but I open to comments and suggestions.  However, before I get all
 the
nitty gritty
detail right, I wanted to start

Re: [E-devel] [RFC] ELM GLView

2011-05-19 Thread Sung W. Park

Thanks for your comments.

Ok, I've added a focus_hook so it now handles events properly.  Now
the elmglviewgears
handles key events and mouse events.  You can rotate it using
Left,Right,Up,Down Arrows
or use the mouse and drag it.  It doesn't actually have a real
trackball feature
implemented so you will notice it not rotating it properly if you
rotate it too much.

I've dropped the elm_glview_z_get function.  I didn't think it was
necessary for now.
maybe we can add it later.

Also, the gl_func_call api was for internal testing purpose and it was
commented out
in the patch but i've removed them completely in this patch.

Also, I've made some changes with the API.   It has been brought to my attention
that there is a performance issue with the way the current APIs are implemented.
Currently, the render function was registered using the

evas_object_image_pixels_get_callback_set

This is so that it doesn't trigger GL rendering when the image object
isn't visible.
Unfortunately, it causes and extra make_current to be called during
the rendering
life cycle of evas.

Evas Render... - (context switch) - EvasGL Renders - (context_switch) - Evas
Finishes rendering

The context switch is quite expensive in the hw driver that i'm using
so it actually
lowers the performance quite a bit.

SO, after discussing it with a few people, we've decided to give an
option to the user
to choose the rendering policy.  If you choose to have render function
render all the time,
it avoids one extra context switch.

EvasGL Renders - (context_switch) - Evas Renders

Hence the render policy of RENDER_POLICY_ON_DEMAND vs. RENDER_POLICY_ALWAYS.

I've also changed the name elm_glview_display_func to elm_glview_render_func

Here's the latest set of elm_glview APIs...
__

typedef enum _Elm_GLView_Resize_Policy
  {
 ELM_GLVIEW_RESIZE_POLICY_RECREATE = 1,
 ELM_GLVIEW_RESIZE_POLICY_SCALE= 2
  } Elm_GLView_Resize_Policy;

typedef enum _Elm_GLView_Render_Policy
  {
 ELM_GLVIEW_RENDER_POLICY_ON_DEMAND = 1,
 ELM_GLVIEW_RENDER_POLICY_ALWAYS= 2
  } Elm_GLView_Render_Policy;


Evas_Object*elm_glview_add(Evas_Object *parent);
void elm_glview_size_set(Evas_Object *obj, Evas_Coord
width, Evas_Coord height);
void elm_glview_size_get(Evas_Object *obj, Evas_Coord
*width, Evas_Coord *height);
Evas_GL_API  *elm_glview_gl_api_get(Evas_Object *obj);
Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
Elm_GLView_Resize_Policy policy);
Eina_Boolelm_glview_render_policy_set(Evas_Object *obj,
Elm_GLView_Render_Policy policy);
void elm_glview_render_func(Evas_Object *obj, Elm_GLView_Func func);
void elm_glview_changed_set(Evas_Object *obj);
__

I'm including the updated elm_glview patch/files and the updated elmglviewgears.

Let me know if you have questions/comments.

cheers,
Sung


On Wed, May 18, 2011 at 7:10 PM, Carsten Haitzler ras...@rasterman.com wrote:

 On Fri, 13 May 2011 00:00:50 +0900 Sung W. Park sung...@gmail.com said:

 ok. missing the focus hook thing u'd need if u want key events to work...
 display_func - render_func_set() probably better. z_get probably can be
 skipped if really too much of a pita.

 whats the gl_func_call api for.. why pass the func - u already set it? could
 set it then call a manual render.. if that's needed. is it really needed?
 curious.  :)

  Hi all,
 
  As you all know, I've been working on adding GL rendering features to Evas 
  and
  we now have an early working version of Evas_GL in the svn.
 
  Since then, there's been a request from people around me for an
  elementary widget that
  allows simple GL rendering.  Since Evas_GL can be seen as a low level API it
  made sense to have a user friendly layer that allows GL rendering.  I
  thought it
  went well with the EFL philosophy.  Take away some control but make it easy 
  to
  use for the users as you go up the layers from Evas-Ecore-ELM- etc.
 
  So, I've decided to take a crack at elm_glview.  By the way, this is
  my first time writing
  an elementary widget so I KNOW I've missed a lot that i need to handle.  
  Also,
  I'm aware of the fact thatI need to handle input events. I'll need to
  figure that out
  but I open to comments and suggestions.  However, before I get all the
  nitty gritty
  detail right, I wanted to start a discussion with the community on the APIs
  and ask for suggestions.
 
  So far, after discussing this with a few people, we've come up with
  the following.
 
     typedef enum _Elm_GLView_Scale_Policy
       {
          ELM_GLVIEW_POLICY_RESIZE,   /** Resize the internal surface
  along with the image */
          ELM_GLVIEW_POLICY_SCALE     /** Only reize the internal image
  and not the surface */
       } Elm_GLView_Scale_Policy;
 
     Evas_Object *elm_glview_add(Evas_Object *parent);
     void

[E-devel] [Review] [Patch] Evas_GL minor fixes + FBO surface reattach bug fix

2011-05-12 Thread Sung W. Park

Hi all,

I'm attaching a patch for Evas_GL that fixes a few minor bugs.
For one, I had issues with stencil and depth format on OpenGL ES on a mobile
device using FBO.

Here's a part of the patch as an example...
(By the way, I'm covering 24bit format with 16bits on OpenGL ES for now... )

@@ -2112,7 +2113,12 @@
   case EVAS_GL_DEPTH_BIT_8:
   case EVAS_GL_DEPTH_BIT_16:
   case EVAS_GL_DEPTH_BIT_24:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ // 24 bit doesn't work... just cover it with 16 for now..
+ sfc-rb_depth_fmt = GL_DEPTH_COMPONENT16;
+#else
  sfc-rb_depth_fmt = GL_DEPTH_COMPONENT;
+#endif
  break;
   case EVAS_GL_DEPTH_BIT_32:
   default:
@@ -2128,7 +2134,11 @@
   case EVAS_GL_STENCIL_BIT_2:
   case EVAS_GL_STENCIL_BIT_4:
   case EVAS_GL_STENCIL_BIT_8:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ sfc-rb_stencil_fmt = GL_STENCIL_INDEX8;
+#else
  sfc-rb_stencil_fmt = GL_STENCIL_INDEX;
+#endif
  break;
   case EVAS_GL_STENCIL_BIT_16:
   default:
@@ -2180,14 +2190,13 @@
 }

Also, I've found a bug where deleting and recreating a surface wouldn't
properly reattach the surface with the FBO in the context.  So that has been
fixed here as well.

The fixes are in the file that I'm attaching: evas_gl_minor_fixes.patch

Also, I'm attaching an evasglgears.c that I've ported from glesgears.
It's still a bit messy but you can play around with it.  left,right,up,
down button works as well. To compile the program, you just need to do

ECORE_PKG = `pkg-config --cflags --libs evas ecore ecore-evas`

evasglgears: evasglgears.c
gcc -g -Wall -o $@ $ $(ECORE_PKG) -lm

You no longer need to link -lGL if you haven't noticed already.

let me know if the patch seems reasonable.

cheers,
Sung
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 59318)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -37,6 +37,7 @@
 struct _Render_Engine_GL_Surface
 {
int initialized;
+   int fbo_attached;
int w, h;
int depth_bits;
int stencil_bits;
@@ -2112,7 +2113,12 @@
   case EVAS_GL_DEPTH_BIT_8:
   case EVAS_GL_DEPTH_BIT_16:
   case EVAS_GL_DEPTH_BIT_24:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ // 24 bit doesn't work... just cover it with 16 for now..
+ sfc-rb_depth_fmt = GL_DEPTH_COMPONENT16;
+#else
  sfc-rb_depth_fmt = GL_DEPTH_COMPONENT;
+#endif
  break;
   case EVAS_GL_DEPTH_BIT_32:
   default:
@@ -2128,7 +2134,11 @@
   case EVAS_GL_STENCIL_BIT_2:
   case EVAS_GL_STENCIL_BIT_4:
   case EVAS_GL_STENCIL_BIT_8:
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ sfc-rb_stencil_fmt = GL_STENCIL_INDEX8;
+#else
  sfc-rb_stencil_fmt = GL_STENCIL_INDEX;
+#endif
  break;
   case EVAS_GL_STENCIL_BIT_16:
   default:
@@ -2180,14 +2190,13 @@
 }
 
 static int
-_create_fbo_surface(Render_Engine *data __UNUSED__, 
+_attach_fbo_surface(Render_Engine *data __UNUSED__, 
 Render_Engine_GL_Surface *sfc, 
 Render_Engine_GL_Context *ctx)
 {
int fb_status;
 
// FBO
-   glGenFramebuffers(1, ctx-fbo);
glBindFramebuffer(GL_FRAMEBUFFER, ctx-fbo);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
   GL_TEXTURE_2D, sfc-rt_tex, 0);
@@ -2221,16 +2230,6 @@
return 1;
 }
 
-/*
-static void
-eng_gl_options_set(void *data, int options __UNUSED__)
-{
-   Render_Engine *re;
-
-   re  = (Render_Engine *)data;
-}
-*/
-
 static void *
 eng_gl_surface_create(void *data, void *config, int w, int h)
 {
@@ -2247,6 +2246,7 @@
cfg = (Evas_GL_Config *)config;
 
sfc-initialized  = 0;
+   sfc-fbo_attached = 0;
sfc-w= w;
sfc-h= h;
sfc-depth_bits   = cfg-depth_bits;
@@ -2435,6 +2435,8 @@
 #endif
 
ctx-initialized = 0;
+   ctx-fbo = 0;
+   ctx-current_sfc = NULL;
 
return ctx;
 }
@@ -2509,6 +2511,7 @@
sfc = (Render_Engine_GL_Surface*)surface;
ctx = (Render_Engine_GL_Context*)context;
 
+   // Flush remainder of what's in Evas' pipeline
if (re-win)
  {
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
@@ -2528,6 +2531,7 @@
 #endif   
  }
 
+   // Unset surface/context
if ((!sfc) || (!ctx))
  {
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
@@ -2545,11 +2549,18 @@
 return ret;
  }
 
+   // Don't do a make current if it's already current
 #if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
-   ret = eglMakeCurrent(re-win-egl_disp, re-win-egl_surface[0], 
-re-win-egl_surface[0], ctx-context);
+   if ((eglGetCurrentContext() != ctx-context))
+ {
+ret =

[E-devel] [RFC] ELM GLView

2011-05-12 Thread Sung W. Park

Hi all,

As you all know, I've been working on adding GL rendering features to Evas and
we now have an early working version of Evas_GL in the svn.

Since then, there's been a request from people around me for an
elementary widget that
allows simple GL rendering.  Since Evas_GL can be seen as a low level API it
made sense to have a user friendly layer that allows GL rendering.  I
thought it
went well with the EFL philosophy.  Take away some control but make it easy to
use for the users as you go up the layers from Evas-Ecore-ELM- etc.

So, I've decided to take a crack at elm_glview.  By the way, this is
my first time writing
an elementary widget so I KNOW I've missed a lot that i need to handle.  Also,
I'm aware of the fact thatI need to handle input events. I'll need to
figure that out
but I open to comments and suggestions.  However, before I get all the
nitty gritty
detail right, I wanted to start a discussion with the community on the APIs and
ask for suggestions.

So far, after discussing this with a few people, we've come up with
the following.

   typedef enum _Elm_GLView_Scale_Policy
 {
ELM_GLVIEW_POLICY_RESIZE,   /** Resize the internal surface
along with the image */
ELM_GLVIEW_POLICY_SCALE /** Only reize the internal image
and not the surface */
 } Elm_GLView_Scale_Policy;

   Evas_Object *elm_glview_add(Evas_Object *parent);
   void  elm_glview_size_set(Evas_Object *obj, Evas_Coord
width, Evas_Coord height);
   void  elm_glview_size_get(Evas_Object *obj, Evas_Coord
*width, Evas_Coord *height);
   Evas_GL_API  *elm_glview_gl_api_get(Evas_Object *obj);
   Eina_Boolelm_glview_mode_set(Evas_Object *obj, Elm_GLView_Mode mode);
   Eina_Boolelm_glview_scale_policy_set(Evas_Object *obj,
Elm_GLView_Scale_Policy policy);
   void elm_glview_display_func(Evas_Object *obj,
Elm_GLView_Func func);
   void elm_glview_changed_set(Evas_Object *obj);
   Eina_Boolelm_glview_z_get(Evas_Object *obj, Evas_Coord x,
Evas_Coord y, Evas_Coord *z);


Internally, elm_glview handles creating an image object, evas_gl
object, evas_gl context,
surface, doing make current for display function. You just need to set
the display_function
callback and put your GL calls in there. The scale policy concerns how the
glview would resize.  setting it to SCALE would keep the current
glview but simply scale
the underlying image.  otherwise, it would recreate the surface.  The
API is pretty straight forward
in my opinion.  It's very much GLUT-like adapted for EFL.

In order to use the elm_glview, you would do something like

main()
{
   ...
   // Add a GLView
   glview = elm_glview_add(win);
   glapi = elm_glview_gl_api_get(glview);
   elm_glview_mode_set(glview, ELM_GLVIEW_ALPHA | ELM_GLVIEW_DEPTH);
   elm_glview_scale_policy_set(glview, ELM_GLVIEW_POLICY_SCALE);
   elm_glview_display_func(glview, (Elm_GLView_Func)draw);
   evas_object_resize(glview, 256, 256);
   evas_object_show(glview);
   ecore_animator_add(on_animate, glview);
   ...
}

on_animate()
{
   elm_glview_changed_set((Evas_Object*)data);
   return EINA_TRUE;
}

// GL calls
draw()
{
   elm_glview_size_get(..., w, h);
   glapi-glViewport(..., w, h);
   ...
}

I guess it's easier to see the sample files and run the code to see
how they actually work.
I'm including a patch that shows the above example.  I'm including the
following files.

1. elm_glview.path
  -. apply using: patch -p0 elm_glview.patch
2. elm_glview.c
  -. copy the file to src/lib
  -. make/ install elmentary
3. elmglviewsample1.c, elmglviewgears.c, Makefile
  -. do a make on the samples using the given makefile.

Ok, that's all for now.  I'd love to hear comments and suggestions on
it as I continue to
work on it.

thanks!

cheers,
Sung


elmglview.tgz
Description: GNU Zip compressed data
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] [Review] [Patch] Evas - evas_object_map_ y-invert case for Native Surface

2011-04-29 Thread Sung W. Park

Hi all,

As I was testing evas_gl, I've ran into a bug when I'm using the
evas_object_map_*
functions.

I don't necessarily want to say it's a bug because it did say
// FIXME: handle yinvert
ERR(not handling inverted y case for map);

So i'm submitting a patch that handles the yinvert case.

Index: src/modules/engines/gl_common/evas_gl_context.c
===
--- src/modules/engines/gl_common/evas_gl_context.c(revision 59024)
+++ src/modules/engines/gl_common/evas_gl_context.c(working copy)
@@ -2688,8 +2688,12 @@

if ((tex-im)  (tex-im-native.data)  (!tex-im-native.yinvert))
  {
-// FIXME: handle yinvert
-ERR(not handling inverted y case for map);
+for (i = 0; i  4; i++)
+  {
+ ty[i] = 1.0 - ty[i];
+ if (yuv)
+t2y[i] = 1.0 - t2y[i];
+  }
  }

cmul = ARGB_JOIN(a, r, g, b);


I'm also submitting an example program that you can run to see before and
after.

let me know if this seems reasonable.

cheers,
Sung
Index: src/modules/engines/gl_common/evas_gl_context.c
===
--- src/modules/engines/gl_common/evas_gl_context.c	(revision 59024)
+++ src/modules/engines/gl_common/evas_gl_context.c	(working copy)
@@ -2688,8 +2688,12 @@
 
if ((tex-im)  (tex-im-native.data)  (!tex-im-native.yinvert))
  {
-// FIXME: handle yinvert
-ERR(not handling inverted y case for map);
+for (i = 0; i  4; i++)
+  {
+ ty[i] = 1.0 - ty[i];
+ if (yuv)
+t2y[i] = 1.0 - t2y[i];
+  }
  }

cmul = ARGB_JOIN(a, r, g, b);
/**
 * Simple Evas_GL example
 */
#include Ecore_Evas.h
#include Ecore.h
#include Evas_GL.h
#include stdio.h
// this gl include we won't need later when Evas_GL.h is complete
#include GL/gl.h

//static Evas_GL_API *evgl;

// demo - animator just to keep ticking over saying to draw the image
static Eina_Bool on_animate(void *data);

// callbacks we want to handle deletion on the object and updates/draws
static void on_pixels(void *data, Evas_Object *obj);
static void on_del(void *data, Evas *e, Evas_Object *obj, void *event_info);

int main(void)
{
   // config for the surface for evas_gl
   Evas_GL_Config config = 
 {
EVAS_GL_RGBA_8, 
EVAS_GL_DEPTH_NONE, 
EVAS_GL_STENCIL_NONE
 };
   // a size by default
   int w = 256, h = 256;
   // some variables we will use
   Ecore_Evas  *ee;
   Evas *canvas;
   Evas_Object *r1;
   Evas_Native_Surface ns;
   Evas_GL *evasgl;
   Evas_GL_Surface *sfc;
   Evas_GL_Context *ctx;
   float half_w, half_h;
   float degree;
   int x, y;
   Evas_Map *map;

   // regular low-leve EFL (ecore+ecore-evas) init. elm is simpler
   ecore_init();
   ecore_evas_init();
   ee = ecore_evas_gl_x11_new(NULL, 0, 0, 0, 512, 512);
   ecore_evas_title_set(ee, Ecore_Evas Template);
   canvas = ecore_evas_get(ee);

   //-//-//-// THIS IS WHERE GL INIT STUFF HAPPENS (ALA EGL)
   //-//
   // get the evas gl handle for doing gl things
   evasgl = evas_gl_new(canvas);
   //evgl = evas_gl_api_get(evasgl);
   // create a surface and context 
   sfc = evas_gl_surface_create(evasgl, config, w, h);
   ctx = evas_gl_context_create(evasgl, NULL);
   //-//
   //-//-//-// END GL INIT BLOB

   // set up the image object. a filled one by default
   r1 = evas_object_image_filled_add(canvas);
   // attach important data we need to the object using key names. this just
   // avoids some global variables and means we can do nice cleanup. you can
   // avoid this if you are lazy
   evas_object_data_set(r1, ..evasgl, evasgl);
   evas_object_data_set(r1, ..sfc, sfc);
   evas_object_data_set(r1, ..ctx, ctx);
   // when the object is deleted - call the on_del callback. like the above,
   // this is just being clean
   evas_object_event_callback_add(r1, EVAS_CALLBACK_DEL, on_del, NULL);
   // set up an actual pixel size fot the buffer data. it may be different
   // to the output size. any windowing system has something like this, just
   // evas has 2 sizes, a pixel size and the output object size
   evas_object_image_size_set(r1, w, h);
   // set up the native surface info to use the context and surface created
   // above
   //-//-//-// THIS IS WHERE GL INIT STUFF HAPPENS (ALA EGL)
   //evas_gl_make_current(evasgl, sfc, ctx);
   evas_gl_native_surface_get(evasgl, sfc, ns);		
   evas_object_image_native_surface_set(r1, ns);
   evas_object_image_pixels_get_callback_set(r1, on_pixels, r1);
   //-//
   //-//-//-// END GL INIT BLOB

   // move the image object somewhere, resize it and show it. any windowing
   // system would need this kind of thing - place a child window
   evas_object_move(r1, 128, 128);
   evas_object_resize(r1, w, h);


   map = evas_map_new(4);
   if (!map) return -1;

   evas_map_util_points_populate_from_object_full(map, r1, 0);
   degree = 30;

   evas_object_geometry_get(r1,

[E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface texture creation patch

2011-04-20 Thread Sung W. Park

Hi all,

I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)

The initial version of the evas_gl that I've submitted had the
following use case.

   evasgl = evas_gl_new(e);
   sfc = evas_gl_surface_create(...);
   ctx = evas_gl_context_create(...);

   // Make current triggers surface texture and FBO to be created
   evas_gl_make_current(evasgl, sfc, ctx);

   // Then you can do a surface_get to retrieve the proper texture and set it
   evas_gl_native_surface_get(evasgl, sfc, ns);
   evas_object_image_native_surface_set(img_obj, ns);

The unnatural thing about this use case is that you have to call the
make_current
one time in order for evas_gl to generate a surface texture.  This is because
you need a context to create a texture.  Unfortunately, this makes the usage
case really awkward.

So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context.  This works because the newly created context
shares resources with evas.  in fact, this is what i'm currently doing
with surface
deletion anyway so I thought this solution was reasonable.

Here's how it looks after you get rid of the make_current:

   evasgl = evas_gl_new(e);
   sfc = evas_gl_surface_create(...);
   ctx = evas_gl_context_create(...);

   evas_gl_native_surface_get(evasgl, sfc, ns);
   evas_object_image_native_surface_set(img_obj, ns);

The patch is pretty small and straightforward.

Let me know what you guys think.

cheers,
Sung
Index: src/modules/engines/gl_x11/evas_engine.c
===
--- src/modules/engines/gl_x11/evas_engine.c	(revision 58768)
+++ src/modules/engines/gl_x11/evas_engine.c	(working copy)
@@ -2229,6 +2229,7 @@
Render_Engine *re;
Render_Engine_GL_Surface *sfc;
Evas_GL_Config *cfg; 
+   int ret;
 
sfc = calloc(1, sizeof(Render_Engine_GL_Surface));
 
@@ -2254,6 +2255,49 @@
 return NULL;
  }
 
+   // Create Render Target Texture/Buffers if not initialized
+   if (!sfc-initialized) 
+ {
+// I'm using evas's original context to create the render target texture
+// This is to prevent awkwardness in using native_surface_get() function
+// If the rt texture creation is deferred till the context is created and
+// make_current called, the user can't call native_surface_get() right
+// after the surface is created. hence this is done here using evas' context. 
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ret = eglMakeCurrent(re-win-egl_disp, re-win-egl_surface[0], re-win-egl_surface[0], re-win-egl_context[0]);
+#else
+ret = glXMakeCurrent(re-info-info.display, re-win-win, re-win-context);
+#endif
+if (!ret) 
+  {
+ ERR(xxxMakeCurrent() failed!);
+ free(sfc);
+ return NULL;
+  }
+
+// Create Render texture
+if (!_create_rt_buffers(re, sfc)) 
+  {
+ ERR(_create_rt_buffers() failed.);
+ free(sfc);
+ return NULL;
+  }
+
+#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
+ret = eglMakeCurrent(re-win-egl_disp, EGL_NO_SURFACE, 
+ EGL_NO_SURFACE, EGL_NO_CONTEXT);
+#else
+ret = glXMakeCurrent(re-info-info.display, None, NULL);
+#endif
+if (!ret) 
+  {
+ ERR(xxxMakeCurrent() failed!);
+ free(sfc);
+ return 0;
+  }
+sfc-initialized = 1;
+ }
+
return sfc;
 }
 
@@ -2487,17 +2531,6 @@
 return 0;
  }
 
-   // Create Render Target Texture/Buffers if not initialized
-   if (!sfc-initialized) 
- {
-if (!_create_rt_buffers(re, sfc)) 
-  {
- ERR(_create_rt_buffers() failed.);
- return 0;
-  }
-sfc-initialized = 1;
- }
-
// Create FBO if not initalized already
if (!ctx-initialized) 
  {
--
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

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

2011-04-18 Thread Sung W. Park

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.comwrote:

 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

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

2011-04-18 Thread Sung W. Park

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

[E-devel] [Review] [Patch] Evas - OpenGL and Evas: eng_window_use (Bug Patch)

2011-04-12 Thread Sung W. Park

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


glview.tgz
Description: GNU Zip compressed data
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-04-11 Thread Sung W. Park

Sounds good.  I'll go ahead and start working on getting the EVAS_GL_APIs
first then.

Before I get started on that though, I thought it would be good to get some
image_object
semantics straight.   I actually had to guess a lot of the image_object API
semantics
to get it running and I think it'll be good to figure all those things out
and also do some
thorough testing.

For example,

Currently, evas_object_image_data_get()  doesn't work if you use the
evas_object_image_native_surface_set() function to set a texture.
Should it actually return the texture data?

also, what about when you resize the data?  how is it supposed to behave if
it calls
evas_object_resize()?  it seems to repeat the texture pattern if it's bigger
than the
fill size that i initially give.  is that correct?

Any thoughts on what should work and which parts are ok for us to ignore?

Suggestions on how I should go about testing and getting the semantics right
would
be much appreciated.

thanks!
Sung



I've mentioned in my previous
email thread that you would have to create a


On Thu, Apr 7, 2011 at 1:33 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Tue, 5 Apr 2011 10:53:45 +0900 Sung W. Park sung...@gmail.com said:

  Great!  Yes, it's definitely not complete.  I'll try to tackle it one by
 one
  as time permits.
 
  Sorry about the Warnings.  I was a little surprised with the lack of
  warnings when I
  compiled the code.  haha...  the -W* flags somehow managed to evade my
  attention. I
  sorta assumed that they were in there.   my script has been fixed now =)
 
  I see that you've fixed all the symbol warnings as well for the gl
  extensions.  Thanks.

 sometimes i feel nice  and do this :)

  
 
  Ok, so I think it would be good to list items that we should work on
 here.
  Here are
  some of the things that come to mind.
 
  1. Provide a subset of GL APIs in Evas_GL.h.  I guess we'll have to
 decide
  on what to
  include.  And then also think about a set of helper functions.

 start with opengl-es2 calls and defined constants

  2. Integrate Evas_GL functionality to other engines. Software engine
 esp.?
  - I think if we use Mesa, most of the GL code in the evas_engine.c in
 gl_x11
  can be
  reused even in the software backend.  Does that sound right?

 for context stuff - yes. for binding fbo. yes. BUT you'll need a way to get
 mesa's FBO ARGB pixel data to BE the pixel data of the image (same ARGB
 pixel
 format, same pointer etc.). that and fixing up mesa's gl symbols NOT to
 clash
 with a real GL via maybe dlopen(... RTLD_LOCAL); and literally stick
 those gl
 api calls in a separate table. how you may or may not get an FBO that mesa
 creates to become an evas image ARGB data (get access to the pointers
 themselves) beats me at this stage. this may require patches to mesa (or
 for
 mesa to USE evas's ARGB pixel pointer AS the FBO pixel data - the other way
 around). but it is possible as all the src for mesa is there.

  3. Fix any necessary FIXME's in the code. =)

 of course :)

  4. Implement an elm widget type of GLView library (but not an elm widget
 as
  I think it's
  unnecessary to make it an elm widget) that would help developers use for
  simple GL rendering since EVAS GL is more low level.  I'm thinking a
 small
  subset
  of functions similar to what GLUT provides would be nice but this also
 needs
  a round
  of discussion.

 i'm up for this being an elm widget - it makes the most sense there. as for
 api
 that will turn up over time - like helpers from glut/glu etc. worlds...
 that
 will happen over time. to start implement just what's needed and build up
 from
 there.

  Anything else?
 
  Thanks again.
 
  cheers,
  Sung


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-04-04 Thread Sung W. Park

Hi,

On Mon, Apr 4, 2011 at 7:27 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Thu, 31 Mar 2011 23:02:09 +0900 Sung W. Park sung...@gmail.com
 said:

 i've had to fix a few things - but it's in svn now. it's not complete - for
 sure. btw. hint:


 export CFLAGS=-W -Wall -Wextra
 :) beware the warnings! also .. for gl proc address getting.. i actually
 get
 the address.. of getprocaddress... i know. it's like checking you have your
 pants on after you've already walked out the front door... but i've
 encountered
 gl libs which dont have it... thus the dlsym fallback. :)


Great!  Yes, it's definitely not complete.  I'll try to tackle it one by one
as time permits.

Sorry about the Warnings.  I was a little surprised with the lack of
warnings when I
compiled the code.  haha...  the -W* flags somehow managed to evade my
attention. I
sorta assumed that they were in there.   my script has been fixed now =)

I see that you've fixed all the symbol warnings as well for the gl
extensions.  Thanks.


Ok, so I think it would be good to list items that we should work on here.
Here are
some of the things that come to mind.

1. Provide a subset of GL APIs in Evas_GL.h.  I guess we'll have to decide
on what to
include.  And then also think about a set of helper functions.

2. Integrate Evas_GL functionality to other engines. Software engine esp.?
- I think if we use Mesa, most of the GL code in the evas_engine.c in gl_x11
can be
reused even in the software backend.  Does that sound right?

3. Fix any necessary FIXME's in the code. =)

4. Implement an elm widget type of GLView library (but not an elm widget as
I think it's
unnecessary to make it an elm widget) that would help developers use for
simple GL rendering since EVAS GL is more low level.  I'm thinking a small
subset
of functions similar to what GLUT provides would be nice but this also needs
a round
of discussion.

Anything else?

Thanks again.

cheers,
Sung
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-31 Thread Sung W. Park

Ok, i'm attaching the latest patch with the fixes discussed from the thread.

I'm attaching the following files.

1. evas_gl.patch
  - This patch includes the image_object_native_surface_set() patch
(I've added the code for hashing the image object.)
  - And, it has the rest of the code that allows evas_gl to run for gl_x11
engine.

2. Evas_GL.h
  - This files goes in
src/lib/

3. evas_gl.c
  - I've added the Evas magic check in evas_gl_new()
  - This files goes in
src/lib/canvas/

4. examples/
  - as discussed in the previous thread.  I've used the animator callback in
evasglgears.
  - i have tried using the image_pixel_get_callback_set as Carsten discussed
but I wasn't
getting any images out on Linux so I've commented it out for now.

Hopefully I've covered all the basis for this patch.
More to come in the near future hopefully.


On Tue, Mar 29, 2011 at 6:05 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Fri, 25 Mar 2011 17:28:48 +0900 Sung W. Park sung...@gmail.com
 said:

   On Wed, 16 Mar 2011 16:26:44 +0900 Sung W. Park sung...@gmail.com
   said:
  
   ok - accounting for some of the comments so far... her'es my take :)
   (finally)! :)
  
   1. you use evas_object_image_pixels_dirty_set(). this is actually
 intended
   to
   work with the image pixel provider to ONLY provide new pixels IF the
 image
   is
   visible and needs drawing. it marks it dirty.. but won't call your
 pixel
   provider until render time and IF the object needs the new pixels. as
 such
   the
   timer_cb should JUST set the dirty flag and then in the pixel
 PROVIDER...
   call
   draw_gl(); at least then invisible objects would stop drawing
 themselevs
   and
   spining using cpu/gpu resources. :)
  
  2.  just in general.. use animators.. not timers. timers is the wrong
 way
   to
   do animating. sure - they work, but animators all tick off at the same
 time
   at
   the same framerate :)
  
 
  for 1  2, it was a quick fix to get the gears running.  with lack of
  documentation
  and all, it was a quick way to get them up and running. i'll take a look
 at
  them.  =)

 sure!

   3. you allow a standard gl api to be used. glEnable(), glBegin() etc.
 etc.
   etc.
   - this is going to probably cause symbol hell and make it hard to
 wrap. i
   really thing all these should become something like:
  
   api = evas_gl_api_get();
  
   api-glEnable(...);
   api-glBegin();
   etc. etc.
  
   ie the evas_gl infra provides SPECIFIC calls you call - these may
 simply be
   the
   exact gl symbols exposed, or wrappers created by evas.
  
   another Style would be:
  
   evas_gl_glEnable(...);
   evas_gl_glBegin(...);
  
   ie expose 1 func in the evas api per gl func to wrap. this is less
   dynamic
   than the first one, but more familiar.
  
 
  I do prefer the first option and i actually have an API in the header
 that's
  commented
  out.  I was thinking that maybe we should start out with what I have
 there
  and then progress
  towards this direction.  Your thoughts?

 i think thats a good course. just clearing up what the final destination
 should
 be so everyone here sees/knows :)

   4. the example include gl headers:
  
   e.g.:
   #include GLES2/gl2.h
   #include GL/gl.h
  
   etc.
  
   as such i think Evas_GL.h should provide everything the app needs
 gl-wise
   in a
   portable way. they don't need top figure out gl vs gles etc. it also
 should
   just stick to the gles subset of gl (gles2 + some pre-made shaders to
 make
   it a
   bit more convenient like gles1.1 for fixed-function stuff).
  
   That's a good idea but I guess a user can be annoyed with not having
 the
  standard
  GL functions?  This would solve the glBindFramebuffer(...,0) issue though
 =)

 well it depends what standard gl functions they want. if we say we do
 opengl-es2 subset AND then some extra functions as helpers to make your
 life
 easier eg like providing some standard shaders, some other things etc.
 that
 are IN ADDITION to gles2 calls, then they can port anything they already
 have
 working on gles2 and then make their code simpler if using evas. no need to
 do
 from day 1. just something to keep in mind imho :)


yeah.. once i get started on this part, I'll factor in these things and then
start a
discussion.



   5. what on earth are we going to do about runtime shader compiling?
 gles2
   problem. it may not provide shader compilers at runtime. shall we just
   agree to
   say if your system doesnt provide runtime shader compiling, then it's
   insuffcient. ? what about shader binary readback? (store the compiled
   binary
   shader).
  
   i haven't had to deal with this issue so i don't know what would be the
  best
  approach but I think it's not a bad idea to say that it's insufficient =)

 i've had to deal with this once before and was faced with readback
 recently.

  can you elaborate on the shader readback?

 give glsl to opengl, then ask gl for the compiled shader binary back so
 NEXT
 time u deal

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

2011-03-25 Thread Sung W. Park

oh great!  I guess you finally got around to it =)

On Fri, Mar 25, 2011 at 1:57 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 14 Mar 2011 10:49:10 +0900 Sung W. Park sung...@gmail.com
 said:

  Ah, i see that you finally had a chance to go through your email piles =)
  welcome back!

 and now... another email pile is being conquered... i hope :)

   gl_x11_evas_engine.patch:
   surprisingly... i have very little to grumble about. the only thing is
 the
   hash
   thing where you comments i didn't think it was necessary as such
 you
   can
   get away with not doing it until you try and duplicate the same texture
 in
   multiple image objects. the compositor does this - or can do it (and it
 is
   used
   for some effects like exposee).  this means it will share the same gl
 image
   wrapper struct etc. etc. which saves some resources.
  
   what you need to do here is put the image in a hash - like the one that
   uses
   pixmap id, but here using texture id. so u'll need another native_hash
 so
   that
   id's dont clash (tex id vs pixmap id) and then put it in there and take
 it
   out
   of it just like the native_hash stuff is done for pixmap id's. :)
 
  my thoughts were that it wouldn't be a big overhead to just create new
 image
  objects
  for each texture reference but you're right in that it does save
 resources
  if you reference them.
 
  by the way, is there a good way to create a unique ID that i can use for
  hashing?
  since pixmap IDs are globally unique, it's good to use it as hash keys
 but I
  think using
  texture IDs would be a bad idea since it's context specific.  any
 thoughts
  on that?

 hmmm as such there HAS to be a unique Id for evas's gl context anyway...
 and
 that text id will have to be unique as otherwise evas's context cant
 identify
 one texture from another... so this id is.. sufficient... is it not? :)


Yes i've realized that and wrote a response in another email.  I've handled
it in the patch
that I last sent.



   now as for target GL_TEXTURE_2D ... vs what?
 GL_TEXTURE_RECTANGLE_NV/ARB
   etc.?
   i'm not sure that's entirely wise? 1D and 3D textures would need proper
   handling then too. also rectangle textures are subject to a different
   coordinate space (in pixels vs 0.0 - 1.0). right now the gl engine
 core
   doesn't use/handle these at all actually. i'm not entirely sure we need
   to/should as rectangle textures come with a whole bunch of
   gotchas/limitations,
   and there are standard npot textures around anyway. :) i'm not really
 sure
   any
   client would need/want to do this?
 
  the thought of having texture target came after seeing #ifdef
  GL_TEXTURE_RECTANGLE_ARB
  in the code.  If you tell the user that
 evas_object_image_native_surface_set
  only
  supports GL_TEXTURE_2D then I guess not having it would be fine.

 well that';s kind of codd i might have implemented, but in reality it
 means
 dealing in 0.0-1.0 coords vs 0-N coords, and as its not universal, we
 need to
 do both.. and anyone that seems to do rectangle textures these days also
 handles npot textures. if they only do pow2 they seem to avoid rectangle
 textures... so... i don't expect rect textures to be used... your
 thoughts?


I think it's fine.  rect textures are nice to use for multi-pass rendering
in my
opinion but, i think it's ok to assume regular texture  2D for now?



   so if you can fix the hash thing... that'd be good. the yinvert patch
 is
   already in svn, so just send an update on the other stuff as above :)
  
  
  I'll do that once I get your response about the hash id.

 above :)



the last patch that i sent already has the above fixes so i'll apply the
other suggestions/comments that you have from the other email responses
before i send an updated patch.


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

2011-03-25 Thread Sung W. Park

On Fri, Mar 25, 2011 at 2:03 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 14 Mar 2011 16:54:00 +0900 Sung W. Park sung...@gmail.com
 said:


  ok, i guess it's not a bad idea to keep track of the objects created via
 the
  gl object
  and delete them during evas_gl_free.
 
  now, i'm not sure if i'm using Eina properly here but would something
 like
  this work?
 
  struct _Evas_GL
  {
 int magic;
 Evas   *evas;
 
 Eina_List  *contexts;
 Eina_List  *surfaces;
  };
 
  .
  EAPI void
  evas_gl_free(Evas_GL *evas_gl)
  {
 Eina_List *l;
 Evas_GL_Context *ctx;
 Evas_GL_Surface *sfc;
 
 ...
 
 // Delete undeleted surfaces
 EINA_LIST_FOREACH(evas_gl-surfaces, l, sfc)
   {
  if (sfc)
 evas_gl_surface_destroy(evas_gl, sfc);
   }
 ...
 
 free(evas_gl);
 evas_gl = NULL;
  }

 no.. the way to do the  list free is more:

 while (evas_gl-surfaces)
  evas_gl_surface_destroy(evas_gl, evas_gl-surfaces-data);

 (the surf destroy handles list removal for us so we know it'll remove the
 item
 we are looking at thus eventually draining the list to be empty)


sounds good. i'll go ahead and apply that.


  EAPI void
  evas_gl_surface_destroy(Evas_GL *evas_gl, Evas_GL_Surface *surf)
  {
 
 ...
 
 // Call Engine's Surface Destroy
 
  evas_gl-evas-engine.func-gl_surface_destroy
  (evas_gl-evas-engine.data.output, surf-data);
 
 // Remove it from the list
 evas_gl-surfaces = eina_list_remove(evas_gl-surfaces, surf);
 
 // Delete the object
 free(surf);
 surf = NULL;
  }
 
  Thanks again!
  Sung


 --
 - Codito, ergo sum - I code, therefore I am --
 The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-25 Thread Sung W. Park

i'm glad we got to this point =)

On Fri, Mar 25, 2011 at 2:59 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Wed, 16 Mar 2011 16:26:44 +0900 Sung W. Park sung...@gmail.com
 said:

 ok - accounting for some of the comments so far... her'es my take :)
 (finally)! :)

 1. you use evas_object_image_pixels_dirty_set(). this is actually intended
 to
 work with the image pixel provider to ONLY provide new pixels IF the image
 is
 visible and needs drawing. it marks it dirty.. but won't call your pixel
 provider until render time and IF the object needs the new pixels. as such
 the
 timer_cb should JUST set the dirty flag and then in the pixel PROVIDER...
 call
 draw_gl(); at least then invisible objects would stop drawing themselevs
 and
 spining using cpu/gpu resources. :)

2.  just in general.. use animators.. not timers. timers is the wrong way
 to
 do animating. sure - they work, but animators all tick off at the same time
 at
 the same framerate :)


for 1  2, it was a quick fix to get the gears running.  with lack of
documentation
and all, it was a quick way to get them up and running. i'll take a look at
them.  =)


 3. you allow a standard gl api to be used. glEnable(), glBegin() etc. etc.
 etc.
 - this is going to probably cause symbol hell and make it hard to wrap. i
 really thing all these should become something like:

 api = evas_gl_api_get();

 api-glEnable(...);
 api-glBegin();
 etc. etc.

 ie the evas_gl infra provides SPECIFIC calls you call - these may simply be
 the
 exact gl symbols exposed, or wrappers created by evas.

 another Style would be:

 evas_gl_glEnable(...);
 evas_gl_glBegin(...);

 ie expose 1 func in the evas api per gl func to wrap. this is less
 dynamic
 than the first one, but more familiar.


I do prefer the first option and i actually have an API in the header that's
commented
out.  I was thinking that maybe we should start out with what I have there
and then progress
towards this direction.  Your thoughts?


 4. the example include gl headers:

 e.g.:
 #include GLES2/gl2.h
 #include GL/gl.h

 etc.

 as such i think Evas_GL.h should provide everything the app needs gl-wise
 in a
 portable way. they don't need top figure out gl vs gles etc. it also should
 just stick to the gles subset of gl (gles2 + some pre-made shaders to make
 it a
 bit more convenient like gles1.1 for fixed-function stuff).

 That's a good idea but I guess a user can be annoyed with not having the
standard
GL functions?  This would solve the glBindFramebuffer(...,0) issue though =)


 5. what on earth are we going to do about runtime shader compiling? gles2
 problem. it may not provide shader compilers at runtime. shall we just
 agree to
 say if your system doesnt provide runtime shader compiling, then it's
 insuffcient. ? what about shader binary readback? (store the compiled
 binary
 shader).

 i haven't had to deal with this issue so i don't know what would be the
best
approach but I think it's not a bad idea to say that it's insufficient =)

can you elaborate on the shader readback?

finally, how would you like me to proceed at this point?  I can make some of

the minor code changes that you've suggested earlier and submit another
set of patches for review and work progressively in terms of glapi and other
features.  let me know.

cheers,
Sung



  Hi all,
 
  Based on the discussions and the comments that I've been getting, I'm
  attaching
  patches for the community to review and test out the code. The patches
  implement
  the code for the gl_x11 backend.  Other backends can be taken care of
 later
  once this has been reviewed.
 
  I apologize if this patch seems a bit big.  I felt that we've had enough
  discussions
  on this topic already in increments and now we're at a point where we can
  see this
  prototype.
 
  Here are the description of the patches:
  (by the way, apply the patches by giving -p0 from evas directory)
 
  1. Evas_Engine_GL_Context.patch
- Basically, this patch replaces all the instances of Evas_GL_Context
 used
  by the gl engines to Evas_Engine_GL_Context.  This was changed
 because
  Evas_GL_Context is exposed to the users by Evas_GL.h and this was
 ok'ed
  in the previous discussion.
 
  2. evas_gl.patch
- This patch includes the image_object_native_surface_set() patch
  since it's required to run evas_gl and this patch hasn't been
 reflected
  in the svn yet.
- And, it has the rest of the code that allows evas_gl to run for
 gl_x11
  engine.
 
  3. Evas_GL.h
- Instead of putting it as part of the patch, I've included them
  separately so it
  can be viewed easily.
- This files goes in
  src/lib/
 
  4. evas_gl.c
- Instead of putting it as part of the patch, I've included them
  separately so it
  can be viewed easily.
- This files goes in
  src/lib/canvas/
 
  5. examples/
- I've included 3 sample programs + Makefile
  a. evasglsample1.c (a simple triangle using GL)
  b. evasglgears.c

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-23 Thread Sung W. Park

Hi Daniel,

Can you elaborate on what you mean by making this as a patch?

I've sent two patches for the files that need to be updated, one of which
has been applied
already.  The other one has been reviewed a little but hasn't been applied
yet.

As for the other files, they need to be freshly added to the svn and since i
don't have
commit access, i've just attached them separately.

Let me know what you mean by it.

cheers,
Sung



On Thu, Mar 24, 2011 at 12:32 AM, Daniel Juyung Seo seojuyu...@gmail.comwrote:

 Can you make this as a patch?

 Thanks.
 Daniel Juyung Seo (SeoZ)

 On Thu, Mar 17, 2011 at 11:34 PM, Sung W. Park sung...@gmail.com wrote:
  Hi again,
 
  On Thu, Mar 17, 2011 at 2:39 AM, Cedric BAIL cedric.b...@free.fr
 wrote:
 
  Hi again,
 
  On Wed, Mar 16, 2011 at 5:02 PM, Sung W. Park sung...@gmail.com
 wrote:
   Hi Cedric,
   Thanks for the review and the comments.  I'm glad to hear that it
 worked
  =)
  
   On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL cedric.b...@free.fr
  wrote:
   On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park sung...@gmail.com
  wrote:
Based on the discussions and the comments that I've been getting,
 I'm
attaching
patches for the community to review and test out the code. The
 patches
implement
the code for the gl_x11 backend.  Other backends can be taken care
 of
later
once this has been reviewed.
   
I apologize if this patch seems a bit big.  I felt that we've had
  enough
discussions
on this topic already in increments and now we're at a point where
 we
can
see this
prototype.
  
   I don't think them to big, they are really easy to understand and
   follow. I really like that !
  
Here are the description of the patches:
(by the way, apply the patches by giving -p0 from evas directory)
   
1. Evas_Engine_GL_Context.patch
 - Basically, this patch replaces all the instances of
 Evas_GL_Context
used
   by the gl engines to Evas_Engine_GL_Context.  This was changed
because
   Evas_GL_Context is exposed to the users by Evas_GL.h and this
 was
ok'ed
   in the previous discussion.
  
   Ok, just reading it. Why do you need to add :
   +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
   +#include EGL/egl.h
   +#else
   +#include GL/glx.h
   +#endif
  
   This part of the code should not be there!  It was from the previous
 hack
   that I did to expose the Evas' GL context.  It was a foolish was but
   it did help me get my feet wet.  I thought I deleted it but it managed
 to
   hide in there somehow.  You can just delete it and it works fine.
 
  So that one is in svn. I also added you in the AUTHORS file, if you
  prefer another mail address, please let me know.
 
 
  Great!  That email address is fine.  wow, thanks.
 
 
 
   in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
   purpose of this patch ? And why do you use evas private configure
   define in a public header ?
  
   By the way the rest of the patch is ok to go in as it is.
  
2. evas_gl.patch
 - This patch includes the image_object_native_surface_set() patch
   since it's required to run evas_gl and this patch hasn't been
reflected
   in the svn yet.
 - And, it has the rest of the code that allows evas_gl to run for
gl_x11
engine.
  
   It seems you are currently destroying a surface using evas context
   instead of the right context, because it could be destroyed. Maybe I
   am wrong, but couldn't you implement a refcount attached to the user
   context to prevent destruction as long as some surface are attached
 to
   it. The rest of the patch looks good to me. Now we should wait for
 the
   software version :-) Hum, maybe it would be good Vincent if you could
   review it to, so we are sure nothing goes wrong when you try to port
   this feature on Windows (I don't see anything obvious, but more eyes
   is always better).
  
  
   Essentially, Evas_GL_Surface is implemented using an FBO and a
   texture and the texture can be seen both by the Evas' GL context and
   then user created context.  the reason why I'm using Evas' context in
   the surface_destroy code instead of using the user context is because
   the user context can be destroyed first.  I could potentially keep a
 ref
   count on the context and destroy it together but I didn't see a point
 in
   doing that here.  it would work just fine using Evas' GL context.
   that's why i make sure that i unbind the context once i use it.  maybe
   there is an angle that i'm not seeing here though.  i'm definitely
 open
   to suggestions. =)
 
  Well, it works, it's just it would be cleaner imho, but as you say not
  that much necessary. Not a blocker in my opinion.
 
 
  It would be cleaner.  Maybe I'll revisit it at a later time.  I'm taking
  tomorrow
  off to get some rest finally =)
 
 
 
3. Evas_GL.h
 - Instead of putting it as part of the patch, I've included them
separately so

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-17 Thread Sung W. Park

Hi again,

On Thu, Mar 17, 2011 at 2:39 AM, Cedric BAIL cedric.b...@free.fr wrote:

 Hi again,

 On Wed, Mar 16, 2011 at 5:02 PM, Sung W. Park sung...@gmail.com wrote:
  Hi Cedric,
  Thanks for the review and the comments.  I'm glad to hear that it worked
 =)
 
  On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL cedric.b...@free.fr
 wrote:
  On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park sung...@gmail.com
 wrote:
   Based on the discussions and the comments that I've been getting, I'm
   attaching
   patches for the community to review and test out the code. The patches
   implement
   the code for the gl_x11 backend.  Other backends can be taken care of
   later
   once this has been reviewed.
  
   I apologize if this patch seems a bit big.  I felt that we've had
 enough
   discussions
   on this topic already in increments and now we're at a point where we
   can
   see this
   prototype.
 
  I don't think them to big, they are really easy to understand and
  follow. I really like that !
 
   Here are the description of the patches:
   (by the way, apply the patches by giving -p0 from evas directory)
  
   1. Evas_Engine_GL_Context.patch
- Basically, this patch replaces all the instances of Evas_GL_Context
   used
  by the gl engines to Evas_Engine_GL_Context.  This was changed
   because
  Evas_GL_Context is exposed to the users by Evas_GL.h and this was
   ok'ed
  in the previous discussion.
 
  Ok, just reading it. Why do you need to add :
  +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
  +#include EGL/egl.h
  +#else
  +#include GL/glx.h
  +#endif
 
  This part of the code should not be there!  It was from the previous hack
  that I did to expose the Evas' GL context.  It was a foolish was but
  it did help me get my feet wet.  I thought I deleted it but it managed to
  hide in there somehow.  You can just delete it and it works fine.

 So that one is in svn. I also added you in the AUTHORS file, if you
 prefer another mail address, please let me know.


Great!  That email address is fine.  wow, thanks.



  in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
  purpose of this patch ? And why do you use evas private configure
  define in a public header ?
 
  By the way the rest of the patch is ok to go in as it is.
 
   2. evas_gl.patch
- This patch includes the image_object_native_surface_set() patch
  since it's required to run evas_gl and this patch hasn't been
   reflected
  in the svn yet.
- And, it has the rest of the code that allows evas_gl to run for
   gl_x11
   engine.
 
  It seems you are currently destroying a surface using evas context
  instead of the right context, because it could be destroyed. Maybe I
  am wrong, but couldn't you implement a refcount attached to the user
  context to prevent destruction as long as some surface are attached to
  it. The rest of the patch looks good to me. Now we should wait for the
  software version :-) Hum, maybe it would be good Vincent if you could
  review it to, so we are sure nothing goes wrong when you try to port
  this feature on Windows (I don't see anything obvious, but more eyes
  is always better).
 
 
  Essentially, Evas_GL_Surface is implemented using an FBO and a
  texture and the texture can be seen both by the Evas' GL context and
  then user created context.  the reason why I'm using Evas' context in
  the surface_destroy code instead of using the user context is because
  the user context can be destroyed first.  I could potentially keep a ref
  count on the context and destroy it together but I didn't see a point in
  doing that here.  it would work just fine using Evas' GL context.
  that's why i make sure that i unbind the context once i use it.  maybe
  there is an angle that i'm not seeing here though.  i'm definitely open
  to suggestions. =)

 Well, it works, it's just it would be cleaner imho, but as you say not
 that much necessary. Not a blocker in my opinion.


It would be cleaner.  Maybe I'll revisit it at a later time.  I'm taking
tomorrow
off to get some rest finally =)



   3. Evas_GL.h
- Instead of putting it as part of the patch, I've included them
   separately so it
  can be viewed easily.
- This files goes in
  src/lib/
 
   4. evas_gl.c
- Instead of putting it as part of the patch, I've included them
   separately so it
  can be viewed easily.
- This files goes in
  src/lib/canvas/
 
  Maybe in evas_gl_new you should check the validity of the Evas object.
  And before calling any evas_gl-evas-engine.func, you should check if
  they are correctly set. That's for the obvious, don't see much more
  than that.
 
  Good point!  I'll add that =)
 
 
   5. examples/
- I've included 3 sample programs + Makefile
  a. evasglsample1.c (a simple triangle using GL)
  b. evasglgears.c (famous gears using Evas_GL)
  c. evasglessample1.c (a simple triangle using GLES)
- You can simply do a make in the directory

[E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-16 Thread Sung W. Park

Hi all,

Based on the discussions and the comments that I've been getting, I'm
attaching
patches for the community to review and test out the code. The patches
implement
the code for the gl_x11 backend.  Other backends can be taken care of later
once this has been reviewed.

I apologize if this patch seems a bit big.  I felt that we've had enough
discussions
on this topic already in increments and now we're at a point where we can
see this
prototype.

Here are the description of the patches:
(by the way, apply the patches by giving -p0 from evas directory)

1. Evas_Engine_GL_Context.patch
  - Basically, this patch replaces all the instances of Evas_GL_Context used
by the gl engines to Evas_Engine_GL_Context.  This was changed because
Evas_GL_Context is exposed to the users by Evas_GL.h and this was ok'ed
in the previous discussion.

2. evas_gl.patch
  - This patch includes the image_object_native_surface_set() patch
since it's required to run evas_gl and this patch hasn't been reflected
in the svn yet.
  - And, it has the rest of the code that allows evas_gl to run for gl_x11
engine.

3. Evas_GL.h
  - Instead of putting it as part of the patch, I've included them
separately so it
can be viewed easily.
  - This files goes in
src/lib/

4. evas_gl.c
  - Instead of putting it as part of the patch, I've included them
separately so it
can be viewed easily.
  - This files goes in
src/lib/canvas/

5. examples/
  - I've included 3 sample programs + Makefile
a. evasglsample1.c (a simple triangle using GL)
b. evasglgears.c (famous gears using Evas_GL)
c. evasglessample1.c (a simple triangle using GLES)
  - You can simply do a make in the directory and it'll compile the
evaglsampl1
and evasglgears by default.


I just tested with a fresh co from SVN and have applied the patches.  I hope
it works.

thanks in advance for your comments!

cheers,
Sung


evas_gl.tgz
Description: GNU Zip compressed data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Review] [Patch] Evas - OpenGL and Evas (Part 4)

2011-03-16 Thread Sung W. Park

Hi Cedric,

Thanks for the review and the comments.  I'm glad to hear that it worked =)

On Wed, Mar 16, 2011 at 11:35 PM, Cedric BAIL cedric.b...@free.fr wrote:

 Hi,

 On Wed, Mar 16, 2011 at 8:26 AM, Sung W. Park sung...@gmail.com wrote:
  Based on the discussions and the comments that I've been getting, I'm
  attaching
  patches for the community to review and test out the code. The patches
  implement
  the code for the gl_x11 backend.  Other backends can be taken care of
 later
  once this has been reviewed.
 
  I apologize if this patch seems a bit big.  I felt that we've had enough
  discussions
  on this topic already in increments and now we're at a point where we can
  see this
  prototype.

 I don't think them to big, they are really easy to understand and
 follow. I really like that !

  Here are the description of the patches:
  (by the way, apply the patches by giving -p0 from evas directory)
 
  1. Evas_Engine_GL_Context.patch
   - Basically, this patch replaces all the instances of Evas_GL_Context
 used
 by the gl engines to Evas_Engine_GL_Context.  This was changed because
 Evas_GL_Context is exposed to the users by Evas_GL.h and this was
 ok'ed
 in the previous discussion.

 Ok, just reading it. Why do you need to add :
 +#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
 +#include EGL/egl.h
 +#else
 +#include GL/glx.h
 +#endif


This part of the code should not be there!  It was from the previous hack
that I did to expose the Evas' GL context.  It was a foolish was but
it did help me get my feet wet.  I thought I deleted it but it managed to
hide in there somehow.  You can just delete it and it works fine.




 in src/modules/engines/gl_x11/Evas_Engine_GL_X11.h . What is the
 purpose of this patch ? And why do you use evas private configure
 define in a public header ?

 By the way the rest of the patch is ok to go in as it is.

  2. evas_gl.patch
   - This patch includes the image_object_native_surface_set() patch
 since it's required to run evas_gl and this patch hasn't been
 reflected
 in the svn yet.
   - And, it has the rest of the code that allows evas_gl to run for gl_x11
  engine.

 It seems you are currently destroying a surface using evas context
 instead of the right context, because it could be destroyed. Maybe I
 am wrong, but couldn't you implement a refcount attached to the user
 context to prevent destruction as long as some surface are attached to
 it. The rest of the patch looks good to me. Now we should wait for the
 software version :-) Hum, maybe it would be good Vincent if you could
 review it to, so we are sure nothing goes wrong when you try to port
 this feature on Windows (I don't see anything obvious, but more eyes
 is always better).


Essentially, Evas_GL_Surface is implemented using an FBO and a
texture and the texture can be seen both by the Evas' GL context and
then user created context.  the reason why I'm using Evas' context in
the surface_destroy code instead of using the user context is because
the user context can be destroyed first.  I could potentially keep a ref
count on the context and destroy it together but I didn't see a point in
doing that here.  it would work just fine using Evas' GL context.
that's why i make sure that i unbind the context once i use it.  maybe
there is an angle that i'm not seeing here though.  i'm definitely open
to suggestions. =)



  3. Evas_GL.h
   - Instead of putting it as part of the patch, I've included them
  separately so it
 can be viewed easily.
   - This files goes in
 src/lib/

  4. evas_gl.c
   - Instead of putting it as part of the patch, I've included them
  separately so it
 can be viewed easily.
   - This files goes in
 src/lib/canvas/

 Maybe in evas_gl_new you should check the validity of the Evas object.
 And before calling any evas_gl-evas-engine.func, you should check if
 they are correctly set. That's for the obvious, don't see much more
 than that.

 Good point!  I'll add that =)


  5. examples/
   - I've included 3 sample programs + Makefile
 a. evasglsample1.c (a simple triangle using GL)
 b. evasglgears.c (famous gears using Evas_GL)
 c. evasglessample1.c (a simple triangle using GLES)
   - You can simply do a make in the directory and it'll compile the
  evaglsampl1
 and evasglgears by default.

 Hehe, looks nice :-) Examples are easy to understand and make this API
 sounds good.

  I just tested with a fresh co from SVN and have applied the patches.  I
 hope
  it works.

 I confirm it run well on my computer :-)

  thanks in advance for your comments!

 That's good ! Could have been my only comment ;-)
 --
 Cedric BAIL



Let me know if you guys have other comments/suggestions.

cheers,
Sung
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

2011-03-14 Thread Sung W. Park

Hi again,

Ok, I'm attaching a new patch.  Read comments below.

On Mon, Mar 14, 2011 at 10:49 AM, Sung W. Park sung...@gmail.com wrote:

 comments here: :)

 evas_gl_context.patch:
 yup! in. i just never handled the y invert case (or lets say.. the
 non-inverted
 case). i just never encountered it so i n


 gl_x11_evas_engine.patch:
 surprisingly... i have very little to grumble about. the only thing is the
 hash
 thing where you comments i didn't think it was necessary as such you
 can
 get away with not doing it until you try and duplicate the same texture in
 multiple image objects. the compositor does this - or can do it (and it is
 used
 for some effects like exposee).  this means it will share the same gl
 image
 wrapper struct etc. etc. which saves some resources.

 what you need to do here is put the image in a hash - like the one that
 uses
 pixmap id, but here using texture id. so u'll need another native_hash so
 that
 id's dont clash (tex id vs pixmap id) and then put it in there and take it
 out
 of it just like the native_hash stuff is done for pixmap id's. :)


 my thoughts were that it wouldn't be a big overhead to just create new
 image objects
 for each texture reference but you're right in that it does save resources
 if you reference them.

 by the way, is there a good way to create a unique ID that i can use for
 hashing?
 since pixmap IDs are globally unique, it's good to use it as hash keys but
 I think using
 texture IDs would be a bad idea since it's context specific.  any thoughts
 on that?



nevermind.  i see your point. =)  since we're in one gl context (or context
that
shares resources), i think just using texture IDs should guarantee its
uniqueness.
i've renamed the original native_hash to native_pm_hash and created a new
one
called native_tex_hash.  i've also added the code that references image
object
if one exists already.

One thing that I didn't add was in _native_free_cb, I didn't know whether I
should free
up the texture there or not.  Any thoughts on this here?

Regards,
Sung


evas_native_set.tgz
Description: GNU Zip compressed data
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

2011-03-14 Thread Sung W. Park

I forgot to do a reply all in my last reply. Anyway... I'll continue on
with the
discussion.

On Mon, Mar 14, 2011 at 11:04 AM, Sung W. Park sung...@gmail.com wrote:

 Hi~

 On Thu, Mar 10, 2011 at 6:11 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 7 Mar 2011 17:33:00 +0900 Sung W. Park sung...@gmail.com
 said:

 ok - i skipped all the way to this mail since this already was discussed
 and
 you've moved on 1 step. :)

  Hi all,
 
  In my earlier post, I've discussed about the issues with getting the
 
evas_object_image_native_surface_set(..., Evas_Native_Surface
 *surf);
 
  function for setting OpenGL output texture.   There was also a
 disucssion
  about how Evas should provide a GL glue layer.  We've discussed two
  proposals.
  After some discussion, I went ahead with the preferred way and have
  implemented the APIs.
 
  The APIs go something like... (in Evas_GL.h)
 
 EAPI Evas_GL *evas_gl_new  (Evas
 *e);
 EAPI Evas_GL_Surface*evas_gl_surface_create  (Evas_GL
 *evas_gl,
  Evas_GL_Config *cfg, int w, int h);
 EAPI Evas_GL_Context*evas_gl_context_create  (Evas_GL
 *evas_gl,
  Evas_GL_Context *share_ctx);
 EAPI Eina_Bool evas_gl_make_current(Evas_GL
  *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
 EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL
 *evas_gl,
  const char *name);
 
 EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
  *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
 
  I actually have the above APIs running on my machine but
  instead of dumping the entire thing, I wanted to get incremental
 comments
  for review.

 thats actually really sensible :) most happy with the way you're handling
 this.
 do some local experiments - see if something works at all or not, see if
 you
 feel comfortable with it, then propose the idea/solution before you go too
 much
 further and flesh it out so as not to waste time. :)

 what you have there looks very sensible to me. its the necessary bits
 you'd
 find in EGL/glX etc. etc. needed to bind gl to evas.. BUT in a way that
 returns
 handles so evas can deal with it nicely :)

 one thing that an eventual implementation of this will need is both a gl
 and
 software path. the software path may literally us importing a special
 build
 of mesa with all the software rendering only enabled and glued to render
 to
 ARGB software buffers. how precisely this will happen/work in detail is a
 matter i guess for actual implementation, BUT it will be needed as we have
 to
 not fail if you switch engines to software. be slower, sure. fail
 (either
 crash, have missing symbols or just whole parts of the canvas go
 unrendered) is
 bad.

 we dont need to do this right away, BUT we do need to design for this
 and at
 the api level that looks all perfectly possible.


 Well, i have i the gl_x11 engine code up and running already so going too
 far isn't an
 issue.  it's too late.  =)  but i don't mind going back and changing things
 up.  it's not too
 bad actually.  also, i just wanted to get my feet wet and so it was a good
 exercise.  now,
 i just need to test it a little more before i can post a patch.

 as you've mentioned, you wouldn't have a problem attaching a software
 implementation of GL
 with this design.  it would have to be tested... i'll do that eventually.



  I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses
 the
  APIs.
 
  Your comments would be very much appreciated.  After the initial review,
  I'll submit
  a RFC for the engine part of the code that I wrote for gl_x11 module.
 
  One issue that I ran into with the above APIs is that Evas_GL_Context is
  already used
  by the gl_common part of the code in the engine module.  Upon discussing
 it
  with Raster,
  the consensus was that it was better to change the internal code since
 it's
  not exposed.
  So, in my implementation, I've changed the internal part to
  Evas_Engine_GL_Context.
  I just wanted to mention that here for now even though it won't show in
 the
  files that i'm
  attaching.

 yup. change the internal type name - no problems there. otherwise i'm
 relatively happy with the api as i see it there and the implementation
 code -
 of course accounting for the fact that the engine will provide a
 gl_surface_create and gl_context_create call.

 now one thing. evas_gl_proc_address_get() is all fine and good. do you
 expect
 apps to have to get proc address of EVERY gl api call? are we not going to
 provide a pre-fetched set of standard gl calls in a struct or something?


 i've put in gl_proc_address initially for getting the GL extension apis.
 for now, i
 was expecting to use regular GL and then eventually do something like

 EAPI Evas_GL *evas_gl_api_get(Evas *e,
 Evas_GL_API *glapi);

 where Evas_GL_API would have all the gl apis filled out by the engine.  Due
 to
 time

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

2011-03-13 Thread Sung W. Park

Ah, i see that you finally had a chance to go through your email piles =)
welcome back!

On Thu, Mar 10, 2011 at 5:52 PM, Carsten Haitzler ras...@rasterman.comwrote:

 On Mon, 28 Feb 2011 17:14:58 +0900 Sung W. Park sung...@gmail.com
 said:

  Hi all,
 
  My name is Sung Park and I've recently started working on a project for a
  Big mobile hw company in Korea ;-)

 oh out with it already! :) everyone knows its samsung. :)


ok, i didn't say it =P



  I've been given the assignment of getting the OpenGL rendered output set
 as
  an image object in Evas, and now I'm getting my feet wet with EFL.

 slosh slosh. welcome to our little corner of the swamp :)

  I'd very much appreciate your guys' help and comments.  Hopefully, I'll
 do
  the same for the community in a short period of time.
 
  So, here I go...
  ---
  From what I've gathered thus far, there is the
 
  evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);
 
  that allows you to either pass in a pixmap or a texture id as part of the
  Evas_Native_Surface structure to set it as the evas_image object source.
  I've noticed that the opengl texture part of the code hasn't been
  implemented yet.  In fact, this is the part that we are interested in
  currently:  to render an image using OpenGL to an output texture (using
 FBO)
  and then to pass that texture to the above function.
 
  Unfortunately, there are a few issues with this approach.   (By the way,
 I'm
  assuming that Evas is running a gl-x11 engine for the sake of discussion)
 
  - The main issue is that the GL application's GL context and the Evas
  engine's GL context is different. Hence a texture created from the
  application cannot be seen from the Evas engine's GL context and will not
  output correct result.  I know that in Windows or Mac, there are ways to
  share texture resources even across processes, but that is not the case
 in
  Linux environment -- you can redirect pixmaps and bind it as a texture
 but
  not explicitly share textures.
 
  - However, there is a way to get around this issue.  Texture resources
 can
  be shared across different contexts by giving the share context as a
  parameter when creating a new context.  For example,
 
 glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
  Bool direct);
 
  the shareList can be Evas' GL context.  Then when the user application
  creates a GL context with this parameter, Evas will be able to see the
  texture.  Unfortunately, this exposes Evas' resources to the users BUT
 there
  isn't really a reasonably better option without writing a ton code...
 
  However, explicitly exposing Evas' GL context just sound like a really
  really bad idea.  One option that I would like to discuss over in a
 separate
  thread is possibly having evas provide a set of open gl glue layer apis
 and
  take care of the creating context and etc. for the users so they don't
 have
  to explicitly deal with Evas' internals.
 
  - There's also the make_current overhead for dynamic scenes since the
  application and evas has to call make_current every time they render.
 I'll
  address that again next time.

 actually i suspect we'll have to accept that there will always be some
 overhead in this whole gl on top of evas thing compared to gl directly in a
 window/buffer/fb yourself, so i don't think it will be TOO bad.


i agree.



  ---
 
  For this thread, I would like to ask the community to review
  evas_object_image_native_surface_set portion of the code that I've added.
  The patch that I'm including is for gl_x11 engine evas_engine.c and
  gl_common's evas_gl_context.c.  I'm also including a simple sample
 program
  that tests the code.  consider the code a minor fix that allows the
 sample
  code to run and maybe you guys can help out completing it.
 
  By the way, It's been quite difficult trying to figure out the semantics
 of
  some of the evas_object_image functions without proper documentations...
 so
  i may have gotten certain things wrong here..
 
  Also, if you look at the sample code, I've used glXGetCurrentContext() to
  grab Evas' current GL context to use it as a share context.  It's a dirty
  trick but it allows me to test the code for now =)
 
  I've also noticed that there was a y-invert texture coordinate bug (GL
 and
  evas has different coordinate system) so I've made those changes in
  evas_gl_context.c
 
  ___
  Here are some comments about the changes I've made.
 
  When using the image object, one would set the data using
 
 evas_object_image_data_set(obj, data);
 
  and internally, this creates a Evas_GL_Image structure.  If I don't use
 the
  above function, it doesn't create a Evas_GL_Image object.
  For setting a native surface opengl texture, I figured it's not necessary
 to
  call above function so i've added some code in the beginning of the
  native_set() that creates

[E-devel] [RFC] Evas - OpenGL and Evas (Part 3)

2011-03-07 Thread Sung W. Park

Hi all,

In my earlier post, I've discussed about the issues with getting the

  evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

function for setting OpenGL output texture.   There was also a disucssion
about how Evas should provide a GL glue layer.  We've discussed two
proposals.
After some discussion, I went ahead with the preferred way and have
implemented the APIs.

The APIs go something like... (in Evas_GL.h)

   EAPI Evas_GL *evas_gl_new  (Evas *e);
   EAPI Evas_GL_Surface*evas_gl_surface_create  (Evas_GL *evas_gl,
Evas_GL_Config *cfg, int w, int h);
   EAPI Evas_GL_Context*evas_gl_context_create  (Evas_GL *evas_gl,
Evas_GL_Context *share_ctx);
   EAPI Eina_Bool evas_gl_make_current(Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
   EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL *evas_gl,
const char *name);

   EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
*evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);

I actually have the above APIs running on my machine but
instead of dumping the entire thing, I wanted to get incremental comments
for review.

I'm now attaching Evas_GL.h and evas_gl.c and a Sample program that uses the
APIs.

Your comments would be very much appreciated.  After the initial review,
I'll submit
a RFC for the engine part of the code that I wrote for gl_x11 module.

One issue that I ran into with the above APIs is that Evas_GL_Context is
already used
by the gl_common part of the code in the engine module.  Upon discussing it
with Raster,
the consensus was that it was better to change the internal code since it's
not exposed.
So, in my implementation, I've changed the internal part to
Evas_Engine_GL_Context.
I just wanted to mention that here for now even though it won't show in the
files that i'm
attaching.

thanks!
Sung
#ifndef _EVAS_GL_H
#define _EVAS_GL_H

#include Evas.h

#ifdef __cplusplus
extern C {
#endif

typedef struct _Evas_GL   Evas_GL;
typedef struct _Evas_GL_Surface   Evas_GL_Surface;
typedef struct _Evas_GL_Context   Evas_GL_Context;
typedef struct _Evas_GL_ConfigEvas_GL_Config;
typedef void* Evas_GL_Func;

typedef enum _Evas_GL_Color_Format
{
EVAS_GL_RGB_8,  // 8 bits per channel
EVAS_GL_RGBA_8,
EVAS_GL_RGB_32, // 32-bits per channel
EVAS_GL_RGBA_32,
} Evas_GL_Color_Format;

typedef enum _Evas_GL_Depth_Bits
{
EVAS_GL_DEPTH_BIT_8,
EVAS_GL_DEPTH_BIT_16,
EVAS_GL_DEPTH_BIT_24,
EVAS_GL_DEPTH_BIT_32,
EVAS_GL_DEPTH_NONE
} Evas_GL_Depth_Bits;

typedef enum _Evas_GL_Stencil_Bits
{
EVAS_GL_STENCIL_BIT_1,
EVAS_GL_STENCIL_BIT_2,
EVAS_GL_STENCIL_BIT_4,
EVAS_GL_STENCIL_BIT_8,
EVAS_GL_STENCIL_BIT_16,
EVAS_GL_STENCIL_NONE
} Evas_GL_Stencil_Bits;

struct _Evas_GL_Config
{
Evas_GL_Color_Format color_format;
Evas_GL_Depth_Bits   depth_bits;
Evas_GL_Stencil_Bits stencil_bits;
};

/**
 * @defgroup Evas_GL group for rendering GL on Evas
 *
 * Functions that are used to do GL rendering on Evas.
 *
 * @ingroup Evas_Canvas
 */

   EAPI Evas_GL *evas_gl_new(Evas *e);
   EAPI void evas_gl_free   (Evas_GL *evas_gl);
   EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl, Evas_GL_Config *cfg, int w, int h);
   EAPI void evas_gl_surface_destroy(Evas_GL *evas_gl, Evas_GL_Surface *surf); 
   EAPI Evas_GL_Context *evas_gl_context_create (Evas_GL *evas_gl, Evas_GL_Context *share_ctx); 
   EAPI void evas_gl_context_destroy(Evas_GL *evas_gl, Evas_GL_Context *ctx); 
   EAPI Eina_Boolevas_gl_make_current   (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_GL_Context *ctx);
   EAPI Evas_GL_Func evas_gl_proc_address_get   (Evas_GL *evas_gl, const char *name);

   EAPI Eina_Boolevas_gl_native_surface_get (Evas_GL *evas_gl, Evas_GL_Surface *surf, Evas_Native_Surface *ns);
 
//   EAPI Evas_GL *evas_gl_api_get(Evas *e, Evas_GL_API *glapi) EINA_ARG_NONNULL(1, 2);

#ifdef __cplusplus
}
#endif

#endif
#include evas_common.h
#include evas_private.h
#include Evas_GL.h

struct _Evas_GL
{
   int  magic;
   Evas*evas;
};

struct _Evas_GL_Context
{
   void*data;
};

struct _Evas_GL_Surface
{
   void*data;
};


/**
 * @addtogroup Evas_GL
 * @{
 */

/**
 * Creates a new Evas_GL object and returns a handle for gl rendering on efl.
 *
 * @param e The given evas.
 * @return The created evas_gl object.
 */
EAPI Evas_GL *
evas_gl_new(Evas *e)
{
   Evas_GL *evas_gl;

   evas_gl = calloc(1, sizeof(Evas_GL));
   if (!evas_gl) return NULL;

   evas_gl-magic = MAGIC_EVAS_GL;
   evas_gl-evas = e;

   return evas_gl;
}

/**
 * Frees the created Evas_GL object.
 *
 * @param evas_gl The given Evas_GL

Re: [E-devel] [RFC] Evas - OpenGL and Evas (Part 2)

2011-03-03 Thread Sung W. Park

Hi Cedric,

On Thu, Mar 3, 2011 at 1:30 AM, Cedric BAIL cedric.b...@free.fr wrote:

 Hi,

 I will do just a quick answer, I don't know if I will have time to
 come back on this subject later.


that's fine.   =)



 On Wed, Mar 2, 2011 at 5:41 AM, Sung W. Park sung...@gmail.com wrote:
  Hi all,
 
  In my earlier post, I've discussed about the issues with getting the
 
   evas_object_image_native_surface_set(..., Evas_Native_Surface
 *surf);
 
  function for setting OpenGL output texture.
 
  The main issue was the GL application having to know Evas' GL context for
  resource
  sharing.  (refer to the older post if this doesn't make sense).  Exposing
  Evas'
  GL context is just a bad idea and it makes things really ugly.
 
  One idea that Cedric mentioned as a response was to have evas provide
 APIs
  that create OpenGL context for the user so everything can be hidden.
 
  I actually had the same idea and the previous post was a way for me to
 setup
  a
  discussion ground for what I'm about to propose.
 
  Instead of just exposing apis for creating contexts, I thought it would
 be
  nice
  for Evas to provide the OpenGL glue layer for the user.  When I say glue
  layer,
  I'm talking about GLX (for X evn in linux), WGL (for windows) and CGL
 (for
  mac).
  The Evas glue layer would provide functions such
  as surface/context creation, make current function and etc.  this allows
  evas to
  hide all the backend specific code in the evas engine and have user deal
  with
  the provided APIs.  This goes along with EFL philosophy I believe.
 
  For surface implementation, the engine can simply create an FBO and a
  render target texture for the user to render to.  The texture can be used
 to
  for setting the native_surface function.
 
  There are two way to go about providing the APIs.  One approach is to
 have
  evas fill out a list of functions from the engine.  This can be similar
 to
  Evas_Engine_Info_GL_X11.
 
  for example,
  ////
  // Option 1
  struct _Evas_GL_Info
  {
int  version;
 
struct {
   Display  *display;
   Evas_GL_APIapi;
} info;
 
struct {
   Evas_GL_Contex*(*create_context)(Evas_GL_Info *info);
   Evas_GL_Surface   *(*create_surface)(Evas_GL_Info *info, const
  Evas_GL_Config *config);
   Eina_Bool(*make_current)(Evas_GL_Info *info,
  Evas_GL_Context *context, Evas_GL_Surface *surface);
   Evas_GL_Func(*get_proc_address)(const char *proc_name);
   const char  *(*query_extension)(void);
   // Need functions that destroy contexts and etc...
} func;
  };
 
  EAPI Evas_GL_Info*evas_gl_info_get(Evas *e);
 
  // Usage Example
  int main()
  {
Evas e* = ...;
 
Evas_GL_Info*glinfo;
Evas_GL_Context *ctx;
Evas_GL_Surface *sfc;
Evas_GL_Config  cfg = {...};
Evas_Native_Surface ns;
 
glinfo = evas_gl_info_get(e);
ctx = glinfo-func-create_context(glinfo, EVAS_GL_API_GLES_2);
sfc = glinfo-func-create_surface(glinfo, cfg);
 
glinfo-func-make_current(glinfo, ctx, sfc);
 
// Use tex and the info in the surface to attach it to the image_object
ns.data.opengl.texture_id = sfc-data.gl.tex;
...
 
return 0;
  }
 
  ////
  Another option is to provide evas-like APIs.
 
  // Option 2
  EAPI Evas_GL  *evas_gl_new (Evas
  *e);
  EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL
 *evas_gl,
  Evas_GL_Config *cfg, int w, int h);
  EAPI Evas_EFGL_Context *evas_gl_context_create (Evas_GL
 *evas_gl);
  EAPI Eina_Bool  evas_gl_make_current   (Evas_GL
  *evas_gl, Evas_GL_Surface *sfc, Evas_EFGL_Context *ctx);
  EAPI Evas_GL_Func  evas_gl_proc_address_get (Evas_GL
 *evas_gl,
  const char *name);
 
  EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
  *evas_gl, Evas_GL_Surface *sfc, Evas_Native_Surface *ns);
 
  // Usage Example
  int main (void)
  {
 Evas e* = ...;
 
 EvasGL *evasgl;
 EvasGL_Surface *sfc;
 EvasGL_Context *ctx;
 EvasGL_Config cfg = { ... };
 Evas_Native_Surface ns;
 
 evasgl = evasgl_get(canvas);
 sfc = evasgl_create_surface(evasgl, cfg, w, h);
 ctx = evasgl_create_context(evasgl);
 
 evasgl_make_current(evasgl, sfc, ctx);
 
 // GL Calls...
 ...
 
 // Get the native surface from EvasGL surface to attach it to the
 image
  object
 evasgl_native_surface_get (evasgl, *sfc, ns);
 ...
  }
 
  //--//
  Personally, I like the option 2 because the APIs look more Evas-like and
  it's evas engine neutral.

 I really do prefer the second one. Sounds much more evas like. But did
 you consider just defining a new evas object ?


Thinking about that solution, I do think it will create more work than
 you second solution without much gain. Just wanted to know

[E-devel] [RFC] Evas - OpenGL and Evas (Part 2)

2011-03-02 Thread Sung W. Park

Hi all,

In my earlier post, I've discussed about the issues with getting the

  evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

function for setting OpenGL output texture.

The main issue was the GL application having to know Evas' GL context for
resource
sharing.  (refer to the older post if this doesn't make sense).  Exposing
Evas'
GL context is just a bad idea and it makes things really ugly.

One idea that Cedric mentioned as a response was to have evas provide APIs
that create OpenGL context for the user so everything can be hidden.

I actually had the same idea and the previous post was a way for me to setup
a
discussion ground for what I'm about to propose.

Instead of just exposing apis for creating contexts, I thought it would be
nice
for Evas to provide the OpenGL glue layer for the user.  When I say glue
layer,
I'm talking about GLX (for X evn in linux), WGL (for windows) and CGL (for
mac).
The Evas glue layer would provide functions such
as surface/context creation, make current function and etc.  this allows
evas to
hide all the backend specific code in the evas engine and have user deal
with
the provided APIs.  This goes along with EFL philosophy I believe.

For surface implementation, the engine can simply create an FBO and a
render target texture for the user to render to.  The texture can be used to
for setting the native_surface function.

There are two way to go about providing the APIs.  One approach is to have
evas fill out a list of functions from the engine.  This can be similar to
Evas_Engine_Info_GL_X11.

for example,
////
// Option 1
struct _Evas_GL_Info
{
   int  version;

   struct {
  Display  *display;
  Evas_GL_APIapi;
   } info;

   struct {
  Evas_GL_Contex*(*create_context)(Evas_GL_Info *info);
  Evas_GL_Surface   *(*create_surface)(Evas_GL_Info *info, const
Evas_GL_Config *config);
  Eina_Bool(*make_current)(Evas_GL_Info *info,
Evas_GL_Context *context, Evas_GL_Surface *surface);
  Evas_GL_Func(*get_proc_address)(const char *proc_name);
  const char  *(*query_extension)(void);
  // Need functions that destroy contexts and etc...
   } func;
};

EAPI Evas_GL_Info*evas_gl_info_get(Evas *e);

// Usage Example
int main()
{
   Evas e* = ...;

   Evas_GL_Info*glinfo;
   Evas_GL_Context *ctx;
   Evas_GL_Surface *sfc;
   Evas_GL_Config  cfg = {...};
   Evas_Native_Surface ns;

   glinfo = evas_gl_info_get(e);
   ctx = glinfo-func-create_context(glinfo, EVAS_GL_API_GLES_2);
   sfc = glinfo-func-create_surface(glinfo, cfg);

   glinfo-func-make_current(glinfo, ctx, sfc);

   // Use tex and the info in the surface to attach it to the image_object
   ns.data.opengl.texture_id = sfc-data.gl.tex;
   ...

   return 0;
}

////
Another option is to provide evas-like APIs.

// Option 2
EAPI Evas_GL  *evas_gl_new (Evas
*e);
EAPI Evas_GL_Surface *evas_gl_surface_create (Evas_GL *evas_gl,
Evas_GL_Config *cfg, int w, int h);
EAPI Evas_EFGL_Context *evas_gl_context_create (Evas_GL *evas_gl);
EAPI Eina_Bool  evas_gl_make_current   (Evas_GL
*evas_gl, Evas_GL_Surface *sfc, Evas_EFGL_Context *ctx);
EAPI Evas_GL_Func  evas_gl_proc_address_get (Evas_GL *evas_gl,
const char *name);

EAPI Eina_Bool evas_gl_native_surface_get (Evas_GL
*evas_gl, Evas_GL_Surface *sfc, Evas_Native_Surface *ns);

// Usage Example
int main (void)
{
Evas e* = ...;

EvasGL *evasgl;
EvasGL_Surface *sfc;
EvasGL_Context *ctx;
EvasGL_Config cfg = { ... };
Evas_Native_Surface ns;

evasgl = evasgl_get(canvas);
sfc = evasgl_create_surface(evasgl, cfg, w, h);
ctx = evasgl_create_context(evasgl);

evasgl_make_current(evasgl, sfc, ctx);

// GL Calls...
...

// Get the native surface from EvasGL surface to attach it to the image
object
evasgl_native_surface_get (evasgl, *sfc, ns);
...
}

//--//
Personally, I like the option 2 because the APIs look more Evas-like and
it's evas engine neutral.

Now, there are a few issues with implementing a glue layer in Evas.

- One major issue is that internally, the surface that the evas provides is
implemented using an FBO. Semantically, FBO index 0 is the main framebuffer
of the screen.  So, when user calls, glBindFramebuffer(GL_FRAMEBUFFER, 0);
the user expects the framebuffer of the surface.  Unfortunately, this isn't
true
when using the evas provided surface. So we'll need to either advise
developers
not to call glBindFramebuffer(GL_FRAMEBUFFER, 0) or hook that
function and have it do what we want to do.  Another idea that came up is
have evas provide a list of GL functions that it supports. That can be
debated later.

- Another issue is that because the application would run in the same

Re: [E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

2011-03-02 Thread Sung W. Park

Hi Cedric,

Thanks for your quick response.  Sorry for my late response.  Yesterday was
a
Korean national holiday so I got to relax a little bit. =)

I'm going to respond to some of your comments below.  I'm glad that you're
picking
up the concerns that I have as well. In fact, I'll go ahead and start
another thread
with suggestions I have later.

On Mon, Feb 28, 2011 at 6:44 PM, Cedric BAIL cedric.b...@free.fr wrote:

 Hi,

 On Mon, Feb 28, 2011 at 9:14 AM, Sung W. Park sung...@gmail.com wrote:
  My name is Sung Park and I've recently started working on a project for a
  Big mobile hw company in Korea ;-)
  I've been given the assignment of getting the OpenGL rendered output set
 as
  an image object in Evas, and now I'm getting my feet wet with EFL.

 That's a terribly usefull and interesting project ! Good to know you
 are starting to work on it !


Yes, I this will make Evas more exciting I think, even though it's pretty
cool already.


  I'd very much appreciate your guys' help and comments.  Hopefully, I'll
 do
  the same for the community in a short period of time.
 
  So, here I go...
  ---
  From what I've gathered thus far, there is the
 
 evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);
 
  that allows you to either pass in a pixmap or a texture id as part of the
  Evas_Native_Surface structure to set it as the evas_image object source.
  I've noticed that the opengl texture part of the code hasn't been
  implemented yet.  In fact, this is the part that we are interested in
  currently:  to render an image using OpenGL to an output texture (using
 FBO)
  and then to pass that texture to the above function.
 
  Unfortunately, there are a few issues with this approach.   (By the way,
 I'm
  assuming that Evas is running a gl-x11 engine for the sake of discussion)

 Well, I dislike that assumption. We really need to have something that
 work whatever the backend and the environment you are running on is
 running. OpenGL is not linked with X except during the initialisation
 process. From my point of view, it's critical that we completly hide
 that step from Evas users.


My assumption here was just for the sake of discussion.  It shows you the
dirtiness/
ugliness of this solution.  As you say, the whole X dependency needs to be
hidden.


  - The main issue is that the GL application's GL context and the Evas
  engine's GL context is different. Hence a texture created from the
  application cannot be seen from the Evas engine's GL context and will not
  output correct result.  I know that in Windows or Mac, there are ways to
  share texture resources even across processes, but that is not the case
 in
  Linux environment -- you can redirect pixmaps and bind it as a texture
 but
  not explicitly share textures.
 
  - However, there is a way to get around this issue.  Texture resources
 can
  be shared across different contexts by giving the share context as a
  parameter when creating a new context.  For example,
 
glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
  Bool direct);
 
  the shareList can be Evas' GL context.  Then when the user application
  creates a GL context with this parameter, Evas will be able to see the
  texture.  Unfortunately, this exposes Evas' resources to the users BUT
 there
  isn't really a reasonably better option without writing a ton code...
 
  However, explicitly exposing Evas' GL context just sound like a really
  really bad idea.  One option that I would like to discuss over in a
 separate
  thread is possibly having evas provide a set of open gl glue layer apis
 and
  take care of the creating context and etc. for the users so they don't
 have
  to explicitly deal with Evas' internals.

 I do agree that we should never expose Evas GL context or we will end
 in very deep trouble. I don't know if that's possible at all, but
 maybe we could let Evas create and provide a GL context that is
 correctly setup to share the texture created with it. Something that
 an upper library could reuse directly without taking care of the
 backend at all.


Yes, that's exactly what I'm thinking as well.
I'll propose a new sets of APIs in a new email thread.


  - There's also the make_current overhead for dynamic scenes since the
  application and evas has to call make_current every time they render.
 I'll
  address that again next time.

 Ok, but don't forget that it would be nice if we don't expose the link
 with X/Linux at all.

  ---
 
  For this thread, I would like to ask the community to review
  evas_object_image_native_surface_set portion of the code that I've added.
  The patch that I'm including is for gl_x11 engine evas_engine.c and
  gl_common's evas_gl_context.c.  I'm also including a simple sample
 program
  that tests the code.  consider the code a minor fix that allows the
 sample
  code to run and maybe you guys can help out completing

[E-devel] Evas - OpenGL and Image Object - evas_object_image_native_surface_set()

2011-02-28 Thread Sung W. Park

Hi all,

My name is Sung Park and I've recently started working on a project for a
Big mobile hw company in Korea ;-)
I've been given the assignment of getting the OpenGL rendered output set as
an image object in Evas, and now I'm getting my feet wet with EFL.

I'd very much appreciate your guys' help and comments.  Hopefully, I'll do
the same for the community in a short period of time.

So, here I go...
---
From what I've gathered thus far, there is the

evas_object_image_native_surface_set(..., Evas_Native_Surface *surf);

that allows you to either pass in a pixmap or a texture id as part of the
Evas_Native_Surface structure to set it as the evas_image object source.
I've noticed that the opengl texture part of the code hasn't been
implemented yet.  In fact, this is the part that we are interested in
currently:  to render an image using OpenGL to an output texture (using FBO)
and then to pass that texture to the above function.

Unfortunately, there are a few issues with this approach.   (By the way, I'm
assuming that Evas is running a gl-x11 engine for the sake of discussion)

- The main issue is that the GL application's GL context and the Evas
engine's GL context is different. Hence a texture created from the
application cannot be seen from the Evas engine's GL context and will not
output correct result.  I know that in Windows or Mac, there are ways to
share texture resources even across processes, but that is not the case in
Linux environment -- you can redirect pixmaps and bind it as a texture but
not explicitly share textures.

- However, there is a way to get around this issue.  Texture resources can
be shared across different contexts by giving the share context as a
parameter when creating a new context.  For example,

   glXCreateContext(Display* dpy, XVisualInfo *vis, GLXContext shareList,
Bool direct);

the shareList can be Evas' GL context.  Then when the user application
creates a GL context with this parameter, Evas will be able to see the
texture.  Unfortunately, this exposes Evas' resources to the users BUT there
isn't really a reasonably better option without writing a ton code...

However, explicitly exposing Evas' GL context just sound like a really
really bad idea.  One option that I would like to discuss over in a separate
thread is possibly having evas provide a set of open gl glue layer apis and
take care of the creating context and etc. for the users so they don't have
to explicitly deal with Evas' internals.

- There's also the make_current overhead for dynamic scenes since the
application and evas has to call make_current every time they render. I'll
address that again next time.

---

For this thread, I would like to ask the community to review
evas_object_image_native_surface_set portion of the code that I've added.
The patch that I'm including is for gl_x11 engine evas_engine.c and
gl_common's evas_gl_context.c.  I'm also including a simple sample program
that tests the code.  consider the code a minor fix that allows the sample
code to run and maybe you guys can help out completing it.

By the way, It's been quite difficult trying to figure out the semantics of
some of the evas_object_image functions without proper documentations... so
i may have gotten certain things wrong here..

Also, if you look at the sample code, I've used glXGetCurrentContext() to
grab Evas' current GL context to use it as a share context.  It's a dirty
trick but it allows me to test the code for now =)

I've also noticed that there was a y-invert texture coordinate bug (GL and
evas has different coordinate system) so I've made those changes in
evas_gl_context.c

___
Here are some comments about the changes I've made.

When using the image object, one would set the data using

   evas_object_image_data_set(obj, data);

and internally, this creates a Evas_GL_Image structure.  If I don't use the
above function, it doesn't create a Evas_GL_Image object.
For setting a native surface opengl texture, I figured it's not necessary to
call above function so i've added some code in the beginning of the
native_set() that creates the object if it's an OpenGL Native Surface.

Also, I didn't think it was necessary to hash the image object so i didn't
add the code in there but I could be wrong I guess.

Finally, I think it may not be a bad idea to add target (texture target)
field in the Evas_Native_Surface but I guess that can be debated.  For now,
i've just hard-coded the field with GL_TEXTURE_2D.

Sorry for the long email.

Your comments on the patches would be very much appreciated.

cheers,
Sung


native_surface_set.tgz
Description: GNU Zip compressed data
--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your

71 matches

Mail list logo