On Wed, 1 Feb 2006 09:01:52 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> babbled:
> On Tue, 31 Jan 2006 15:14:36 +0100 Florent Thiery <[EMAIL PROTECTED]> > babbled: > > > I really am sorry about this, i didn't read realize that the discussion > > had beed closed already... Just a simple question though, how is the > > rendering mode of Mac OSX? Hardware or software? Will the Aero engine of > > Vista be the first totally-hardware-driven graphical engine? > > you need to do some reading up on graphics and display systems. a LOT. NB - i said this because your question shows you dont understand graphics and windowing systems very well. they are insanely complex beasts and are more often more complex than kernels - if not many times more complex sometimes just because of sheer scope. you cant ask such generalised questions about systems so complex - without qualifying what you are assuming and intending by the question. > > Carsten Haitzler (The Rasterman) a écrit : > > > > >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. > > > > > > > > > > > When on 600 mHz, i see speed problems in the animation when i launch a > > prog from the dock (ibar), in fact whenever there is something heavy > > (animated background, shining follower)... Of course when the hard drive > > spins down it's pretty slow :) > > > > >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. > > > > > > > > > > > I forget it, i promise :p > > > > > -- > ------------- 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 > -- ------------- 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
