Zero Architecture Overview

[17:48] <myren> if they're so good, why does xrandr crash 3/4?  :/
[17:49] <Dragon22> because xrandr is a peice of shit
[17:49] <Dragon22> and you probably arent running xorg 7.1
[17:49] <myren> hopefully that'll fix soon
[17:49] <myren> i am
[17:49] <myren> better than my other laptop, which stopped running X altogether after the ati superpatch
[17:49] <Dragon22> I hate randr though
[17:49] <Dragon22> its a hacky solution
[17:50] <myren> kp is hacking up something hopefulyl better
[17:50] <myren> the input subsystem sucks too
[17:50] <Dragon22> keithp will probably not live long enough to fix X
[17:50] <myren> we'll just have to clone him
[17:50] <Dragon22> probably
[17:51] <myren> whatever, opengl will eventually take over for X
[17:51] <Dragon22> I've been working on a replacement for X for awhile now
[17:51] <myren> i replaced your brain with a small scenix/ubicom SX75
[17:52] <myren> i dont actually think X will be replaced
[17:52] <Dragon22> I do
[17:52] <myren> it'll just be a lot less important part of the equation
[17:52] <Dragon22> I dont care if Im the only user using my replacement
[17:52] <Dragon22> atleast I wont be using X like you dorks
[17:52] <myren> what is your replacement?
[17:52] <Dragon22> Zero.
[17:53] <myren> i see no reason to deliberately remove X support from Opengl
[17:53] <myren> which is basically how its stacking up
[17:53] <myren> furthermore, xcb is actually managable as a protocol
[17:53] <Dragon22> SteveDekorte: zero is also the name of the other good guy in megaman x
[17:54] <Dragon22> SteveDekorte: basically, X's big brother; cooler, faster, stronger, and has a lightsaber. Thus, I named my windowing system Zero.
[17:55] <Dragon22> myren: see, Im not removing X from opengl. Im making opengl the lowest API.
[17:56] <myren> xgl is opengl is the lowest layer
[17:56] <myren> which i think is wrong
[17:56] <myren> aiglx would be better
[17:56] <Dragon22> no no no myren 
[17:56] <Dragon22> xgl /doesnt/ use opengl as the lowest drawing API
[17:56] <myren> i know its a dance, but thats not what i meant
[17:56] <Dragon22> it still uses xlib shit
[17:57] <Dragon22> also, aiglx and xgl are not competing technologies
[17:57] <Dragon22> aiglx and xgl are used together... aiglx just allows you to accelerate indirect rendering contexts (ie, GL apps) inside of something that holds the real rendering context (ie, xgl)
[17:58] <myren> i need to go kindnap alp and force him at gunpoint to finish xnb so i can start dicking with this better
[17:58] <myren> can you use aiglx inside of xgl?
[17:58] <Dragon22> not only you can, but you have to
[17:58] <Dragon22> if you dont, you dont have hardware accelerated GL apps
[17:59] <myren> yeah, i was under the impression that was a much more difficult task in xgl
[17:59] <Dragon22> its not
[17:59] <myren> accelerated gl apps
[17:59] <Dragon22> the task doesnt belong to xgl, thats why
[17:59] <Dragon22> its a severe lack of feature inside glx
[17:59] <myren> (i really need a usb hub that works.  :/ )
[17:59] <Dragon22> glx can't accelerate indirect rendering contexts
[18:00] <Dragon22> glx over networked X, and xgl produces indirect rendering contexts
[18:00] <myren> eeww
[18:00] <myren> how would you pixel shade your screen in aiglx, v. pixel shade your screen in xgl?
[18:00] <Dragon22> only apps that directly communicate to the hardware (ie, via mesa->dri, or via whatever nvidia's shit does) get a direct rendering context
[18:00] <myren> thats my big q
[18:01] <Dragon22> myren: uh, define pixel shade your screen
[18:01] <myren> modify your render framebuffer
[18:01] <Dragon22> you mean the one belonging to your GL app?
[18:01] <myren> no
[18:01] <myren> X
[18:01] <myren> all of it
[18:01] <myren> as postprocessing
[18:01] <Dragon22> thats done by xgl
[18:02] <Dragon22> xgl 'owns' all the windows.
[18:02] <myren> aiglx does everything as offscreen buffers, but how does it composite them together?
[18:02] <Dragon22> it doesnt
[18:02] <Dragon22> your compositor does
[18:02] <myren> thats what i was afraid of
[18:02] <Dragon22> uh, no.
[18:02] <Dragon22> thats the way its supposed to work
[18:02] <myren> ok, so aiglx does need xgl
[18:02] <Dragon22> no.
[18:02] <Dragon22> aiglx works fine in normal 2D X
[18:03] <Dragon22> but you dont need it outside of one major case
[18:03] <myren> and you just pray your 2d composoting is accelerated?
[18:03] <myren> thats a terrible plan
[18:03] <Dragon22> no, in 2D X, theres no compositor
[18:03] <Dragon22> it passes it through to a direct context
[18:03] <Dragon22> unaltered
[18:04] <myren> wait wait back up
[18:04] <myren> there's offscreen buffers from aiglx
[18:04] <myren> that go to a compositor
[18:04] <Dragon22> no
[18:04] <myren> :-/
[18:04] <myren> what am i missing?
[18:04] <Dragon22> aiglx only passes it onto another app
[18:04] <Dragon22> in this case, it passes it onto xgl
[18:05] <Dragon22> xgl renders it into a FBO or a pbuffer, and then composits everything
[18:05] <myren> it being an offscreen buffer?
[18:05] <myren> what was it?
[18:05] <Dragon22> lets try this again
[18:05] <myren> < Dragon22> aiglx only passes it onto another app
[18:05] <myren> please do.  sorry.
[18:05] <Dragon22> in this case, your opengl app's command stream is passed into another app
[18:05] <Dragon22> actually, lets make this easier
[18:05] <Dragon22> there are three cases
[18:06] <Dragon22> case 1) your GL app is on the same machine as your x server, and you get a direct context
[18:06] <myren> i was under the impression that aiglx was largely a compositing system that worked by processing pixmaps into textures, and then aiglx did the compositing
[18:06] <Dragon22> case 2) your GL app is on another machine, and you get an indirect context
[18:06] <myren> otherwise why is ext_pixmap_to_texture the core requirement for aiglx
[18:06] <myren> case 3) your app is not opengl
[18:06] <Dragon22> case 3) your GL app is connecting to XGL.
[18:07] <Dragon22> in case 2 and 3, aiglx comes in handy
[18:07] <Dragon22> in case 1, aiglx doesnt enter the equation
[18:07] <myren> aiglx made my desktop much faster, even without opengl apps
[18:07] <Dragon22> in case 2, its just passed to a direct context, as if it was case 1 (with minimal overhead)
[18:07] <Dragon22> myren: well
[18:08] <Dragon22> GTK is now a GL app technically
[18:08] <Dragon22> it can do it's own rendering, via cairo, with GL, via glitz-GL
[18:08] <myren> i could adjust transaprency of non gtk based apps
[18:08] <myren> thats defiantely a compositing engine doing that
[18:08] <Dragon22> thats compiz at work, myren 
[18:08] <Dragon22> compiz technically is the compositing engine
[18:08] <Dragon22> KDE also has its own built in
[18:09] <Dragon22> xorg 7.1 now has xcomposite enabled by default, so you can hook right until the compositing subsystem
[18:09] <Dragon22> now, rewind a bit
[18:09] <Dragon22> ext_pixmap_to_texture is required for both xgl and aiglx if you want stuff to work correctly
[18:10] <Dragon22> its /absolutely/ required if you want aiglx to work in xgl
[18:10] <myren> nvidia just got ext_pixmap_to_texture, and its had working xgl for a while.
[18:10] <Dragon22> ext_pixmap_to_texture is a very specific method to deal with offscreen buffers
[18:10] <myren> i'm not meaning to be deliberately contrary, sorry
[18:10] <Dragon22> mesa had it first, actually
[18:10] <Dragon22> nvidia implemented it in their own GL lib not too long after
[18:11] <Dragon22> the extension was specifically requested by aiglx and xgl
[18:11] <myren> they only just got around to letting aiglx work
[18:11] <Dragon22> and it exists purely to assist working with offscreen buffers
[18:11] <myren> and i thought it was because ext_pixmap_to_texture wasnt implemented
[18:11] <Dragon22> yeah, like 3 montsh ago, myren 
[18:11] <myren> really?  i was thinking 1-2 weeks.
[18:11] <Dragon22> no, its been awhile I think
[18:12] <Dragon22> now, the tricky part is, xgl refuses to work withut ext_pixmap_to_texture, but it doesnt /require/ it
[18:12] <myren> http://digg.com/linux_unix/Beta_version_of_new_NVIDIA_Linux_driver_with_AIGLX_support_available
[18:12] <Dragon22> they did that because the alternative just sucked.
[18:12] <myren> beta, 47 days ago.
[18:12] <Dragon22> I've written stuff just like xgl, myren 
[18:13] <Dragon22> I can totally see why they want ext_pixmap_to_texture
[18:13] <myren> xgl isnt exactly the most brillaint piece of functionality.  a drawing engine on top of opengl?
[18:13] <Dragon22> no.
[18:13] <Dragon22> xgl is not that.
[18:13] <myren> being able to turn your native drawing buffer into a texture, that would be handy
[18:13] <Dragon22> xgl is simply the windowing system drawer on opengl
[18:13] <Dragon22> its half of the compositor.
[18:14] <Dragon22> xgl does what OSX did 2 years ago
[18:14] <myren> uh yeah, pardon, that was a pretty bad mischaracterization.
[18:14] <Dragon22> draw windows in offscreen buffers, and display them on the screen
[18:14] <Dragon22> thats all xgl does
[18:14] <Dragon22> its one third of the problem
[18:15] <Dragon22> the other third was solved by aiglx; allowing opengl apps to still be hardware accelerated
[18:15] <Dragon22> the third third needs to be solved by GTK and QT and friends: whats in the window itself drawn by opengl
[18:15] <myren> no, thats the layer above bytecode isnt it
[18:16] <Dragon22> once all three parts of the problem are solved, we'll be back in buisness
[18:16] <myren> cairo - glitz
[18:16] <Dragon22> yup, basically cairo and glitz
[18:16] <Dragon22> gtk and qt are both going full cairo and glitz usage
[18:16] <myren> how did aiglx let me toss around video windows and have them be wobbly and stuff?
[18:16] <myren> if opengl wasnt doing the compositing
[18:16] <Dragon22> myren: wrong thing
[18:16] <Dragon22> myren: aiglx probably wasnt involved at all
[18:16] <myren> compiz, ok
[18:17] <Dragon22> compiz does the wobbly
[18:17] <myren> i dont think compiz could do that on the cpu
[18:17] <myren> it certainly didnt make my cpu spike
[18:17] <Dragon22> compiz uses opengl to do the wobbly
[18:17] <Dragon22> compiz /doesnt/ need aiglx to hook into xgl's compositor
[18:17] <myren> i guess it can just permute the offscreen buffer to make wobbly
[18:17] <Dragon22> it uses the xcomposite extension
[18:17] <Dragon22> myren: you know how this works, right?
[18:17] <myren> yes
[18:17] <Dragon22> in xgl, all apps draw to a texture
[18:17] <myren> i thought i did
[18:17] <myren> yeah yeah
[18:18] <Dragon22> you map the texture onto a standard gl quad
[18:18] <myren> ext_pixmap_to_texture
[18:18] <Dragon22> you can do whatever you want to the quad
[18:18] <Dragon22> make it transparent, make it wobbly, anything you can do in normal openg
[18:18] <myren> xgl is simple to understand, thats why i keep asking about aiglx.  ;)
[18:18] <Dragon22> just because an app generated the texture doesnt make it special
[18:18] <Dragon22> aiglx only solves one problem: allows GL apps to draw to a texture.
[18:18] <Dragon22> /thats it/
[18:18] <Dragon22> nothing more
[18:19] <myren> brain... hurting....
[18:19] <myren> yes, that does make sense though, its in the name.
[18:19] <Dragon22> it only solves the accelerated opengl app in xgl problem
[18:19] <Dragon22> exactly
[18:19] <myren> thats patently false
[18:19] <Dragon22> it's name describes it well
[18:19] <Dragon22> no, its true
[18:19] <myren> its enough to provide compiz the tools it needs to ...
[18:19] <Dragon22> no
[18:20] <Dragon22> compiz doesnt need aiglx
[18:20] <myren> compiz can run on aiglx alone
[18:20] <Dragon22> compiz uses the xcomposite extension to hook into xgl's compositor
[18:20] <myren> sans xgl
[18:20] <Dragon22> yes, it can do that too
[18:20] <myren> thats what i dont understand
[18:20] <Dragon22> because compiz is making its own compositor
[18:20] <myren> out of opengl pieces
[18:20] <Dragon22> yup
[18:20] <myren> ?
[18:20] <myren> right ok
[18:20] <Dragon22> it does basically what xgl does
[18:20] <Dragon22> its rather redundant
[18:21] <myren> how does compiz render the app... oh, it just turns the pixmap into textures, right
[18:21] <Dragon22> yeah, basically
[18:22] <Dragon22> see, compiz hijacks the rendering pipeline at a different spot
[18:22] <Dragon22> the xcomposite extension allows compositing apps like compiz to hijack away
[18:22] <myren> yeah, i'm kind of curious how it steals everyone's output
[18:22] <Dragon22> using that extension
[18:23] *** binary42 quit (Connection timed out)
[18:23] <myren> now i really need to kidnap alp and force him at gunpoint to complete xnb
[18:23] <Dragon22> well, myren 
[18:23] <Dragon22> when Im done my system, all of this shit will be redundant
[18:24] <Dragon22> x, compiz, your window manager, the server-side part of aiglx should all be in the same damn app
[18:24] <SteveDekorte2> Dragon22: what are you writting?
[18:24] <Dragon22> its 100% redundant to have twenty thousand fucking peices all doing shit to solve one fucking task
[18:24] <Dragon22> SteveDekorte2: zero, as I said. a new windowing system
[18:24] <myren> compiz does a pretty good job of hacking the critical points
[18:25] <Dragon22> myren: no it doesnt
[18:25] <SteveDekorte2> ok, so no UI toolkits?
[18:25] <myren> capture window output, transform, composite
[18:25] <myren> pure opengl path
[18:25] <Dragon22> SteveDekorte2: that'll be apart of zeroApp
[18:25] <Dragon22> SteveDekorte2: the UI is drawn by the display server
[18:25] <SteveDekorte2> and no text rendering either?
[18:25] <myren> hey, random q, what do you two use for window managers?
[18:25] <Dragon22> no more retarded client side widgets
[18:26] <Dragon22> no more HI IM A GTK APP AND I LOOK LIKE THIS, AND HI IM A QT APP AND I LOOK LIKE THAT
[18:26] <myren> by enforce conformity.  ;)
[18:26] <Dragon22> if I specify a fucking look, then all fucking apps will fucking look like it
[18:26] <SteveDekorte2> Dragon22: I don't see how that's up to the windowing layer
[18:27] <Dragon22> SteveDekorte2: its not
[18:27] <Dragon22> but that doesnt say it cant be in the display engine
[18:27] <Dragon22> I wanna minimize the gap between desktop environment and windowing system
[18:27] <Dragon22> the gap in how X works just fucks everything up
[18:28] <myren> the diversity of annoying totally different widgets is testament to its viability
[18:28] <Dragon22> gnome and kde wouldnt even exist if X had their own official desktop environment intergrated right into the Xserver and xlib and shit
[18:28] <Dragon22> myren: yes, and its costing linux users.
[18:28] <myren> hey, more power to you if you think you can outdo them all and any different future paths
[18:28] <myren> that came out as more sarcastic than i intended
[18:29] <myren> i just think the problem is,
[18:29] <SteveDekorte2> Dragon22: so you're going to write the UI toolkit in C++?
[18:29] <Dragon22> SteveDekorte2: HELL. NO.
[18:29] <Dragon22> what is wrong with you? of all the languages you could have thought of, you thought of C++?
[18:29] <Dragon22> wtf man
[18:29] <myren> if X had their own official desktop environment, we'd be lucky to be running motif.
[18:30] <Dragon22> myren: there was an implication that this was bizzaro earth and X didnt suck there
[18:30] <myren> right.  =]
[18:32] <myren> i need to go avoid starving, thank you for the opgnl discussion
[18:32] <Dragon22> seeya myren 
<pre>