[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] For review: ANGLE_timer_query extension



My stupid idea was that I mentioned alternative API approaches like callbacks at the beginning of this thread. I did that before really thinking trough Bens usecase. I've meanwhile thought about Bens usecase a lot, and I realized that the API proposed is pretty perfect and that I've proposed as fodder for discussion a lot of stupid things. The elegance of Bens proposal is that the API is fine grained, convenient to wrap and doesn't impose a particular way to handle timer queries onto a users application code.

I don't think that spinloops in themselves are an issue. We already have a working spinloop, it's called gl.finish. Spinlooping without a synchronization command is an issue, because that can mutate to a deadspinloop. But this is relatively easy to safeguard against and throw an exception, which I'd consider a reasonable approach to migitate the issue and educate users on how not to use the API, without changing the API flavor.

I need this extension. Ben needs this extension. There are other people that need it. Other than safeguarding against erregious spinlooping it's pretty much perfect as is. Yes, it's not a _javascript_-y API, but making it more _javascript_-y doesn't improve the API. It just adds more overhead you have to take care of. Like hiding a handle, why's an integer a better handle than a handle? If you want to make it more _javascript_-y you can wrap your own utility code around it, which is what most users of the API would do anyway, because using it naked is nearly never really useful. Yes it's not a simple API, but it's also not a simple problem.

Can we stop bikeshedding on the API flavors and accept the API that ben proposed, with the provision that there is a solution to throw people out of spinlooping with a simple query counter reset since state change?