On Tue, Oct 28, 2008 at 3:24 PM, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > 2008/10/28 T Willingham <[EMAIL PROTECTED]> >> >> To give a context for all of this, I am applying a non-linear >> transformation to an object on every frame. (Note: non-linear, so a >> matrix transform will not suffice.) > > Any reason why you can not do this in the vertex shader? You really should > avoid trying to touch the vertices with the CPU if at all possible.
The per-vertex computation is a quite complex time-dependent function applied to the given domain on each update. Yet even if it were simple, I would still first implement the formulas in Haskell and leave the optimization for later, if at all. The current C++ implementation which uses userland-memory vertex arrays already performs very well. On Sat, Nov 1, 2008 at 3:15 AM, Neal Alexander <[EMAIL PROTECTED]> wrote: > Even when generating one or more copies of "world" per frame the performance > stays fine and allocations are minimal. Who says? That may be your particular experience from your particular tests. In my case, any copy of the "world" on each frame would have a catastrophic effect on the framerate, for any such definition of "world". > From what ive seen, the OpenGL calls are whats going to bottle neck. Yes, that may as well be a tautology. The problem is sporadic lag and jittering from occasional large allocations and/or garbage collection from frequent small allocations. It's a unique situation where even the best profiling cannot pinpoint what is blatantly obvious to the human eye. Though the profiler may register it as 0.01%, the actual effect is glitchy behavior which comes off as unprofessional. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
