On Mon, 30 Jan 2006 19:37:40 +0100 Florent Thiery <[EMAIL PROTECTED]> babbled:
> Yup :) How far is the implementation of Hardware/Software OpenGL > rendering? Of course the most interesting part of it would be the > hardware opengl. I must say that DR17 is a performance-eater, except if > you cut off lots of effects... Which is sad. I got 1,3 Ghz Banias, and i > can't stand the unresponsiveness while working at 600 Mhz.... it works like a charom on my 1ghz pentium-m even when it clocks down to 600mhz to save battery. i don't see whatt hey problem is? i dont see it being unresponsive ever - UNLESS the disk has spun down and needs to spin up to read data - that's a matter of e paging everything off disk as much as possible (to save memory) and really relying on disk cache from there on in to keep it at a moments access away. opengl wont happen. 1. it cannto do shaped masks sanely. to do this we'd need a gl frontbuffer with alpha (can do) then a way to read just the alpha convert to a mask, and punt back as a shape - the problem coems with reading the alpha pixels. glReadPixels() is about the same speed as contiental drift in my experience. every driver i have ever played with goes through one of the slowest paths possible reading pixals to client memory because its not considered an important thing to accelerate as it not only has to read pixels off card to system ram, it also is just not used much as this alone has inherent slowdowns. also gl requires TONNES of video ram - every window with gl in it will rEQUIRE the equivalent of its size in video ram IN ADDITION to all images in the textures. every client window (every xterm, mailer window, firefox whatever) will need its dimentions in video ram. ok- lets stake an example. we have a web browser 1000x1000 pixels, now 20 xterms each 500x300 pixels, another set of windows (miscellanous ones) with a total surfacfe area of lets say another 1000x1000 pixels. now the desktop bg (1600x1200) this woudl be 19Mb of video ram gone. this doesnt include the source textures (likely another few mb). basically every gl window will REQUIRE a backbuffer if we likely it or not as rendering to afrontbuffer is just not sane. this doesn't include the other problems with gl - like big drosp in performance due to fat lock contention between the xserer and the wm sicne gl goes via direct rendering. if u are doing combinations of 2d and 3d u will see things stutter and jerk. so - forget it. the gl engine also can't handle multiple contexts correctly atm (ie more than 1 gl window) and share textures between them - i tried to make it wokr in theory but it seesm to have issues and frankly - i have neither the time nor inclination to fix it - so this alone bars it from ever working. now as i was saying - forget it. i am sick to death of having this discussion every few weeks - repeatedly. either setup up - learn to code and fix the engine yourself and address these issues in the gl engine AND in all the gl drivers - or accept what u get. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
