On Fri, 14 Dec 2001, Filip Spacek wrote:
> Hello everyone! > > I have posted a first version of my GGIMesa patch at > > http://www.student.math.uwaterloo.ca/~fspacek/ggimesa.diff Wow! 64K is an amazing size... (If it would only be compressed 64K... ;-)) And your gear-on-AAlib screenshot looks very cool, too. Great work! > It is mostly functional, but there are still some (mostly > implementation) details that need to be worked out, so I didn't post > it to Mesa3D ml, but rather I seek advice here. > > I have tested the patch on 8 and 16 bit single and double buffered X > target as well as the aalib target. I currently have no other targets > to test it on (though KGI is very very very close) so if anybody wants > to give it a shot somewhere else I'd be grateful. > > I've radicaly changed the interface. It follows the ideas I've > outlined in my previous mail (since nobody seemed to have any serious > objections). > > First of all, I've attempted to follow the usual extension use > patterns more closely. The functions ggiMesaInit and ggiMesaAttach are > now mandatary and GGIMesa will _not_ take care of them silently if you > forget them. > > The new interface is as follows: > > int ggiMesaExtendVisual(ggi_visual_t vis, GLboolean alpha_flag, > GLboolean stereo_flag, GLint depth_size, > GLint stencil_size, GLint accum_red_size, > GLint accum_green_size, GLint accum_blue_size, > GLint accum_alpha_size, GLint num_samples); > > This is probably the first call one should make. It will "extend" > visual by certain capabilities that cannot be specified by > ggi_mode. Note however that everything that can be specified by > the visual's mode is. That means RGB/COLOR_INDEX as well as > single/double buffering is set up depending on the current mode. > > Note that call to this function is not strictly necessary. As the > name suggests, it merely extends the visual. So if the > capabilities that can be provided by the ggi-only visual are > sufficient you don't need to call this. > > ggi_mesa_context_t ggiMesaCreateContext(ggi_visual_t vis); > > Create a context capable of being used to render on visual vis. > This is a fundamental one, and one would usually call it after the > visual is properly extended. > > void ggiMesaMakeCurrent(ggi_mesa_context_t ctx, ggi_visual_t vis); > > Bind the context to the visual and select the context as the > current one. > > Now for the issues: I would very much like to make Mesa use as transparent > as possible. What that means is that once the user extends the visual, it > should be possible to ggiSetMode and GGIMesa would adapt. Currently (using > the GGI_CHG_APILIST) it is capable of resizing the necessary buffers > (there is a bug in the code and it crashes after about a 20 resizes). Do you make use of libbuf for buffer support? If yes, you might found a bug in libgalloc (libgalloc is responsible for resizing of resources). > However I am not at all sure about what to do about change of graphtype. You have to overload libggi's internal getapi function. The libxmi's X/Xlib targets gives you an idea how to do that. But be careful: you must call libggi's getapi function, too. Otherwise LibGGI wouldn't handle the reloading of its own default sublibs anymore. > Obviously there will be a lot of state that will no longer be valid in a > different graphtype. Currently I'm thinking of complely invalidating > contexts bound to the visual but that violates my ideal of making the use > totally transparent. If anybody has a better idea please help me out. > > What I'm trying to do is make up an interface that would be useable even > later when a windowing system uses ggi and wants to do Mesa with direct > rendering. What I'm envisioning is some sort of flow-through visual for > the window in question (I know Stefan has done something similar for > Berlin). For this to work, it must be possible to resize the visual > without disturbing the context. Sounds good. > I have not submitted this patch to Mesa3d yet, and I will not do so until > the above issues are resolved. Since most of the problems are GGI and not > Mesa related, I figured I'd post this here now. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
