On Thu, Dec 05, 2002 at 03:21:46PM -0600, D. Hageman wrote: > 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.
One could argue that the analogies themselves were already a drift from the technical discussion. > > > 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. I didn't say that the drivers *wouldn't*, but that they *shouldn't have to*. There's a difference. > > > 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. True, but I still dont' think that putting it into the driver itself is "doing 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". Okay. -- http://trikuare.cx ------------------------------------------------------- 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
