I doesn't know other people was working on opengl windowing systems, maybe we can collaborate in the future.
I think is a good idea use the X server as a trampoline as you can use all those accelerated drivers out there, i am sticking with Jon's work on mesa standalone as i really want to replace the X server, although i am exploring Kdrive without input nor fonts, etc. with only the GLX and DRI extensions, hopefully it will work with those accelerated drivers. For font management i am using FTGL that uses freetype2 but with caching and cool things. I too require a 2.6 kernel to use all the new fancy stuff (input layer, alsa, sysfs, udev, futexes, eventpoll, etc.). I am trying to deviate from windows and use instead workspaces, i really think that windows are counter-productive, workspaces would be a better way to manage different apps and tabs within apps, and yes, it will be a workspace called "desktop". This work is in its infancy, but i am glad that we probably will have something usable before longhorn get's out the door, although we're late with MacOSX. -solca On Tue, Nov 04, 2003 at 05:52:14PM -0700, Michael Dreesen wrote: > > [EMAIL PROTECTED] is also supposed to be working on an OpenGL based > windowing > > system. I don't know the status of his code. > > Hi Guys- > My mike-d.org server is down, this is my work address. Here's the > status of my OpenGL window system: > > client/server is working. > > Right now communication is done with FIFOs (named pipes). There is a > comand to server FIFO, data to server, command to client, and data to > client. Performance is great. > > window compositing is working. > > Only one gl context is used for the window system's drawing. Clients > draw into the back buffer. When a client wants to draw to a window, the > server checks to see if that window's back texture is already on the > back buffer (each window has two textures, front & back, the front > texture is what is displayed). If that window is not the current owner > of the back buffer, a swap may occur. If there is a valid window on the > back buffer it's contents are read out using glCopyTexSubimage. The > window that requested drawing has it's back texture drawn to the back > buffer with a simple textured GLQUAD, now the graphics operations may > take place. When a client calls the Update function for a window, the > window hierarchy's front textures are composited up, and at the top > level the front texture for each client's toplevel window is drawn as a > textured GLQUAD, a glxSwapBuffers is then called. > > One key feature is that the window system tries to keep a constant > framerate. The system does as many operations as it can in each > timeslice before it calls glxSwapBuffers. In this manner, 20 clients > get graphics throughput that is just as fast as one client (as tested so > far). 2D graphics drawing is very fast. > > window input is working. > > selection is done by using each window's unique id as it's "color". > These are drawn on the backbuffer (swap if needed, don't draw if > "SELECTION" is already valid for the back buffer). As pointer motion > occurs, lookups are done with glReadPixels to find the window id, from > there the event is sent to the client over the command to client fifo. > > font drawing is working. > > I'm using freetype 2.0. The server does glyph caching for each bitmap > generated by freetype, for each face. Characters are drawn by using the > 256 level grayscale bitmap to modulate the alpha channel of the > current drawing color. > > So far, in my demo, I start up the server, have twelve clients connect, > each displaying different text. Each client displays a couple child > windows. When you click and drag on a client, the client follows your > pointer (server sends pointer event, client keeps track of motion and > says move my window), and some animated lines are drawn to show that the > system can "walk and chew bubble gum at the same time". I also have > alpha blending turned on, so it's quite pretty. > > I plan on having a "shell" application like an X window manager. I'm > currently preparing to port my X widget set to the new system. I need > to get mike-d.org back up so I can receive mail at home. I'll post a > screenshot of the server in action to comp.windows.x in a couple hours. > > I also need to type up a more complete design document, I hope some of > that makes sense. > > Cheers, > Mike > > > > Jon Smirl wrote: > >--- Otto Solares <[EMAIL PROTECTED]> wrote: > > > >>How can i interface with your changes?, currently i open the fbdev, > >>mmap fb and mmio region, set desired fbdev mode, load r200 dso, pull hooks > >>and > >>everything is ok from there. The only thing i dislike with the current > >>aproach > >>is that we need root privs and dri_util is not a clean API. > > > > > >Just stick with what you are using until my code stabilizes. The mode/EDID > >stuff is not working and it is necessary for removing FB. > > > > > >>I have everything working, including input (from new input layer), sound > >>(via openal and alsa) and graphics (DRI standalone mesa from > >>Mesa-newtree). > >> > >>My concentration is on the opengl desktop now, the problems i see is the > >>lack > >>of overlays and pbuffer/fbconfigs support. > > > > > >I know what is needed to do the pbuffer changes but I haven't gotten to > >them > >yet. If you want to start on this the first thing needed it to modify the > >clear > >routines in the DRM driver to not use fixed addresses for the framebuffer. > >Right now they use the 2D layer to do the clear and the code is hardcoded > >to > >use the main front/back buffers. Clear needs to work like all of the other > >3D > >code and allow the buffer addresses to be passed in. > > > >Another project is font support. Font bitmaps need to be a global > >resource. I > >haven't worked out the best scheme for supporting them. One thought is to > >create a texture handle for each face/style. Then during rendering > >intercept > >the calls for using mips maps to do the scaling. This will give you the > >rectangle the font needs to be generated for. Generate it, or find it in a > >cache, and let the hardware continue. Doing it this way will let a window > >be > >scaled without loss of detail. When the window is maginifed the font > >bitmaps > >will get generated with more detail. Brain or Keith might already know the > >most efficient way to do this. > > > >[EMAIL PROTECTED] is also supposed to be working on an OpenGL based > >windowing > >system. I don't know the status of his code. > > > >===== > >Jon Smirl > >[EMAIL PROTECTED] > > > >__________________________________ > >Do you Yahoo!? > >Protect your identity with Yahoo! Mail AddressGuard > >http://antispam.yahoo.com/whatsnewfree > > > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
