On Thu, 18 Jan 2007 20:48:37 +0100 Rene Jensen <[EMAIL PROTECTED]> babbled:
> 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. cool cool - i've been a bit busy to answer anyway :) > 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. this would be prohibitively evil in the world of evas - it gets a lot of its speed from not going overboard in this regard. if anything you want a loadable module at most. the issue here though is not if you make it a separate process via ipc/shm or a thread or a loadable module. the problem is evas has no CONCEPT of "shaders" (i like to call them filters). evas needs to have a concept of filters added where one object can FILTER another (ie you apply the filter object to another - it works like a clip object, BUT applies a filter instead, like blur, bumpmap, sharpen etc. etc.). i would suggest that it be a bit more rigid with specific well-known and used effects (as i just mentioned) so they can be specifically implemented in the evas engines for just that purpose. if you export a generic shader language you basically screw performance outside of opengl permanently. > > 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 > 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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
