Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
Jesse Luehrs wrote: On Wed, 01 Feb 2006 15:35:39 -0500 Curtis Napier [EMAIL PROTECTED] wrote: I disagree, how are the devs at Xorg supposed to know that this is an issue if no one tells them? I know this particular issue is very well known in the Xorg community but nevertheless, someone should file a bug outlining what E17 needs from Xorg in order to use openGL. Call it a feature request or whatever but Xorg needs to be informed, even if all they say is Sorry, can't help you at least it will be officially documented. This is the way FOSS works. Somehow I can't imagine that the Xorg devs are unaware that everyone wants GL acceleration and true transparency(: On other, less widespread issues, I agree with you, but I know that if I were an Xorg dev, I would have been tired of people asking about those two things about a year ago. Jesse They probably are sick and tired of it. I would be if I was them. But that doesn't matter. The FOSS way is for *someone* to inform them of E17's needs. If they choose to work on that or not is up to them but if no one ever tells them E17's needs then they absolutely *WON'T* work on it at all. ps. you sent this to me personally instead of to the list in general. I'm forwarding your email to the list, I hope that's OK. --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
On 2/2/06, Curtis Napier [EMAIL PROTECTED] wrote: SNIPThey probably are sick and tired of it. I would be if I was them. Butthat doesn't matter. The FOSS way is for *someone* to inform them ofE17's needs. If they choose to work on that or not is up to them but if no one ever tells them E17's needs then they absolutely *WON'T* work onit at all.Actually, the FOSS way, is to scratch yourself if it itches. So you need it, you hack it. ;)
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
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? 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 --- 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=lnkkid3432bid#0486dat1642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
On Tue, 31 Jan 2006 15:14:36 +0100 Florent Thiery [EMAIL PROTECTED] wrote: 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? OSX is entirely hardware rendered. OSX is also not just a window manager. Enlightenment would need far more acceleration support from X in order to get performance like OSX has. If you are concerned about other platforms getting hardware rendering on the desktop before us, go bug the Xorg devs(: Jesse --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
On Tue, 2006-01-31 at 09:48 -0600, Jesse Luehrs wrote: On Tue, 31 Jan 2006 15:14:36 +0100 Florent Thiery [EMAIL PROTECTED] wrote: 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? OSX is entirely hardware rendered. OSX is also not just a window manager. Enlightenment would need far more acceleration support from X in order to get performance like OSX has. If you are concerned about other platforms getting hardware rendering on the desktop before us, go bug the Xorg devs(: that's a very bad advice. don't bug the xorg devs, unless its important. they have enough trouble reviving x as it is. Jesse --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
On Tue, 31 Jan 2006 18:31:18 +0200 [EMAIL PROTECTED] wrote: that's a very bad advice. don't bug the xorg devs, unless its important. they have enough trouble reviving x as it is. I wasn't entirely serious(: My point was just that they would actually be able to do something about it, unlike the Enlightenment devs. I totally agree that bugging devs in general is a bad thing. Jesse --- 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
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. 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=lnkkid=103432bid=230486dat=121642 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] OpenGL rendering: sorry i won't open my mouth again
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=lnkkid=103432bid=230486dat=121642 ___
