Re: [E-devel] [E-Devel] [Patch] Old Evas OpenGL Engine

[Carsten H. (T. R. <ra...@ra...>]

On Wed, 21 Apr 2010 18:38:26 +0200 Hugo Camboulive <hug...@gm...>
said:

hmmmm.. hrmml.. hmmm... what.. hmm.. it'd have been nice if you talked about it
first... where do we start... 

ok 1 - not excited about the idea of maintaining 2 different gl engines. 1 of
which is behind feature-wise and likely will stay so. ugh. pain. and not to
mention - confusion. why didn't you try and make the current engine
"shaderless" ? if thats what you want... thats what you should have done, but
maintaining the old enigne i dont see as a viable thing for the future. the
current gl enigne is both gl and gl-es specifically to reduce maintenance over
time in merging 2 engines, and sharing development. the shaders were a decision
based on gl-es - gl-es1.1 is zero shaders. 2.0 is ONLY shaders. no fixed
function. if we need shaders for yuv anyway... we need to go alll-shader to
keep both desktop and embedded gl unified. decent modern gl 3d units for
desktop do shaders well enough - though it seems you are unlucky. as gl moves
on and gets more features to make using it for 2d better, older 3d units will
become unusable, so more weight to "why keep the old gl enigne around"?

but.. kudos to doing the work to bring it back - thumbs up there. and in
giving it back to us, but... for maintenance - it'd need to go into the current
gl enigne. that will also lead to a lot of #ifdefs, more dlsym fun funding
functions and more complex paths, but its better than having 2 completely
separate enignes :( i actually want to kill off lots of engines to reduce down
to just software based ones with minimal "target" interfacing (and thats 32bit
- kill 16bit ones), and the gl one(s). things like xrender, directfb etc. will
die. so adding this old gl enigne is going against the grain.

now effort in the current gl enigne.. in the right way... would stand the test
of time. :)

> Hi,
> 
> I have backported the old OpenGL engine (pre Dec 2009) on top of the latest
> evas in a non intrusive way.
> 
> What was done :
> - I reused the old gl_common (renamed unsurprisingly to... gl_common_old).
> - At configure time, an option (--enable-gl-old), decides if we're going to
> link to gl_common_old instead of gl_common
> - The code actually only supports what was in when it was dropped (which
> means no maps... for now - but it does not crash either), I only slightly
> modified the structures, some functions, added some placeholders, etc... to
> make it work with gl_x11
> 
> Why it was done :
> I work for a company that develops an embedded system that uses the EFL. We
> use a GMA embedded chipset, which is not supported by the new opengl engine.
> We can't really afford to use the cpu intensive software rendering on our
> small system, nor can we stay at an old evas version (because that means no
> bugfixes, and being stuck with an old evas+ecore+edje+elementary because of
> the dependencies).
> What that means is we *will* take care of maintaining the old engine. It may
> not be ultra fast support with one dedicated man working on it, features may
> lag behind the other engines, but it will be kept alive and working.
> 
> So here's the patch, we really hope it will be integrated back :)
> 
> Best regards,
> 
> Hugo Camboulive
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...