On Thu, 10 Mar 2011 11:15:58 -0300 Solerman Kaplon <soler...@gmail.com> said:
> Em 10-03-2011 06:11, Carsten Haitzler (The Rasterman) escreveu: > > > > 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. > > One can design to support it, but I heard recently from the Mesa guys that > the pure software renderer is too slow for any practical usage. depends what you do - if you are rendering solid triangles or just gouraud shaded ones... it should be fine. even if its slow - it's better than not working at all. sure - if people are rendering a whole screen of complex 3d content but if its some smaller/simpler things like 3dicons or other simpler and more limited stuff... then it will be ok. but the important bit here is about not BREAKING compatibility - having missing content. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
