Sorry sorry sorry for not being able to answer sooner! Shortly after I proclaimed that my Internet connection was back, I lost it again. This time I won't say a word. Perhaps right now you are a reading a letter delivered by a pigeon, who knows.
Carsten Haitzler (The Rasterman) wrote: > On Fri, 15 Dec 2006 19:17:53 +0100 (CET) [EMAIL PROTECTED] babbled:H >> Why is creation of OpenGL rendering context handled by Evas (or whoever it >> is) itself? The user has a fine control of creation of X11 resources, >> therefore in my eyes it would seem a natural extension to this frame of >> mind that the user can control how GL resources should be handled also. >> > > because a gl context is global. evas has no idea what the current context > color > is, texture, multitexture mode, currently bound fragment shader, etc. etc. > etc. > > because it is a state engine that you change the state of - if evas comes in > not knowing the state when drawing, it will have to either reset every > possible > known state value each time, or, as it does currently, manage its own state. > > >> My motivation for asking lies in the concept I proposed last I wrote, >> namely a video-processing framework based on a shared OpenGL context (i.e. >> indirect rendering which will make it possible to use textures, >> shader-programs etc shared between processes). >> > > ok. now to this. the problem with this is that evas is meant to be INDEPENDENT > of its rendering engine at the api level. i am very loathe to expose the > engine > to the evas api if i can. this means an evas program can change engines at > will > and "just work" (tm). > I was fishing for this answer way back. Figured someone would come clear eventually. Anyway, you are absolutely right. A videoframework shouldn't depend on a GUI. In the audio world JACK (an out-of-process sound stream system) has taken a different course, namely to let every node in the processing graph (e.g. a sound filter adding echo to a signal) run as a separate process with the GUI of its own choice, Gtk, Qt etc. So each node owns an XWindow of it's own. Of course it puts a heavier load on the Window Manager, since it now becomes in charge of giving the user a chance to find his way through a lot of windows. DSSI (an in-process plugin-system) also lets the plugin handle it's own GUI, which run in it's own thread. I'll stick to this model. > what you want is basically evas as a gl front-end for yourself, not as a > display independent canvas. now there is nothing wrong with that - but it is > not one of the goals of evas to do that. that is why you will not find the gl > context exposed and find it very hard to get TO internals. it's all nicely > abstracted away. now i do know what you want - you want to be able to place a > gl rendered scene (3d maybe) in a canvas. if its 3d you want - then we are > talking major nasty work as we then need to expose EVERY engine, all the > engine > capabilities and ways in and out of that sanely. if its just 2d - maybe its > something that needs to go into evas anyway. i have been considering filter > objects for example that would provide filtering like gaussian blur, sharpen, > etc. etc. so maybe what you want is somewhere on the todo in a more generic > way? > I can positively say that even just the basic needs skyrockets past what any reasonably ordinary canvas engine needs to handle. 3D, 2D, dedicated mask-generation, motion tracking and so on. The list is endless. It would cause you more trouble than good to do that. But thanks for offering. Regards, Rene Jensen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
