On Thu, 5 Dec 2002, magenta wrote: > > You just love those bad analogies. Do the people losing their ass in the > stock market try to use a VW Bug as a boat? >
Careful, let us stick to the technical discussion rather then personal attacks on how I choose to express myself. Don't attack the analogies themselves, but rather the content that preceeded them and the point that they were very obviously making. You failed to do that. > > Another point ... do you know which platforms LD_PRELOAD works on and > > which doesn't? Have you completely done your research on it? DRI at the > > momment only supports a subset of the platforms out there, but it doesn't > > do anything too radical that prevents it from being ported to most if not > > all platforms ... how will this preloading runtime libraries effect that? > > But the very mechanism by which the DRI drivers are loaded pretty much > guarantees that LD_PRELOAD will be available. And still, I'd rather see a > simple wrapper library be supported on ALL OpenGL drivers for ALL platforms > which support LD_PRELOAD than to see it limited to one or two DRI drivers > (even if it's on all platforms which support DRI). This is incorrect. Every modern OS that I am aware of supports dynamic loading of code. Not every modern OS supports dynamic preloading of code. As far as the last half of your statement, who is to say that it won't be implemented in all DRI drivers? Who is to say that the vendors won't work to implement it into their drivers? You are making assumptions about the future again. > > Again, you are making claims that you can not support. You have no proof > > that the "added overhead, instability, and inconsistancy" would be cause > > by the other solutions. Let us keep the FUD to a minimum please. > > I'm just speaking from experience in dealing with large software systems > where decisions like this are added in post-hoc. I don't think we are in a post-hoc type of mode. We don't have a deadline or anything like that. We haven't had anything up until this point ... it won't matter if we take a little bit of time and do it right. > > I don't think so ... don't think of it as being included in the driver as > > that the driver looks at a common interface to determine how it should > > render the data. If the interface is written correctly, then the code > > wouldn't have to be recreated in each driver causing your so called > > inconsistancies. I think we all know what we want, but getting there is > > just going to have to take some friendly debate and in the end ... some > > willingness to be flexible with the people that are doing most of the > > work. :-) > > Why should the people doing "most of the work" (i.e. the DRI drivers) have > to work on this other random thing too, when I could write a > perfectly-functional wrapper library by myself in a relatively short time > which would work with ALL OpenGL drivers under ALL UNIXes which support > LD_PRELOAD? I'm not expecting "someone else" to write a wrapper library > like this; what I'd hope is that by discussing the wrapper library, the DRI > developers *wouldn't* end up spending a lot of time on implementing > something which is, IMO, unnecessary. The flexibility I mention concerning the people doing most of the work is that *they* have done most the work and by all rights should have the most say in what happens. If you think you can code up an OpenGL wrapper that can do just this in a short amount of time why don't you code one up as a demo case. We can try it out, see how it works and go from there. The faster you can turn out the demo case, probably the better so we can hopefully move onto other things that may not be so "unnecessary". -- //========================================================\\ || D. Hageman <[EMAIL PROTECTED]> || \\========================================================// ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
