On Tue, 4 Dec 2001, Filip Spacek wrote: > exactly what kind of behaviour wrt ggi visual and mode is expected of an > extension so I hope somebody here will be able to point out any > inconsitencies.
Well, of a pure GGI extension, we'd expect that it could deal with re-creating whatever extra context it has when ggiSetMode is called. I wouldn't hold GGIMesa to that standard, though, since it is meant to provide Mesa look and feel. > 3. void GGIMesaMakeCurrent(GGIMesaContext ctx) > I'm not exactly sure whether this function is strictly necessary. > Is it even possible to have more than one ggi_visual_t open at a > time? Yes, but in GGI each visual has it's own context. I don't know enough about Mesa to even know properly what the Mesa function does :-) > I an uncertain about some parts of the above interface: Is extending a > visual through GGIMesaCreateVisual a good idea? Currently it assumes that > a valid mode is set and uses the set dimensions to allocate necessary > buffers. Would it be a better idea to instead create a full blown > GGIMesaSetMode? It would make integration with libGAlloc much easier but > I'm not sure whether it would be flexible enough. I would concentrate on what would make Mesa API users most comfortable. > Now for an implemetation issue: Double Buffering. Currently, I have > implemented double buffering using ggiSet*Frame() family of calls. Is this > the only implementation I should provide? Should I provide alternate > implementation using ggiSetOrigin in case the virtual resolution is large > enough? And what about the case when the target does not support any sort > double buffering and the user requests double buffered OpenGL? If the > target didn't bother emulating double buffering should Mesa do it? I'd say not, "frames" basically use the SetOrigin trick but conceal it from the user. If a GGI target doesn't support them but does support setorigin, time is better spent fixing that target IMO. -- Brian
