On Mon, 5 Jul 2004, david daniell wrote:
Ok so I understand why the redrawing of arrays is so slow.... it seems like there's no data reduction in the redraw process, so for instance if I have an array that's 10 seconds long @ 44100 hz, it runs through all 441,000 data points in the rendering of the array on-screen. So, of course there's a slow-down for that. But is there any way to impose some sort of data-reduction in the visual rendering of the arrays?
Well, I have reviewed most of that code (g_array.c), with the intent of reorganizing and/or partially rewriting later, but that was a few months ago.
I recall there's something that, beyond a certain array size (2000?) picks up only 300 values in the array for the redraw. So IMHO the problem is not there.
The biggest bandwidth problem from the array editor, is that when refreshing the array's waveform, it resends all of the viewable values. Even if that's limited to 300, if it's to be done several times a second, it sucks bandwidth like mad, especially if that's transmitted as a Tcl "line coords" command with no possible way for the Tcl side to decide how/if/when to redraw it.
What I want is: modified array data must be sent as a diff; Tcl side stores a data-reduced version of the array at all times (level of indirection) and/or shared memory is used (if possible); Tcl side renders when it wants to, based on received notifications of modifications; Tcl side gets several rendering options, instead of just one big "create line"; my intuition tells me that joining several "create line" might help with redraw speeds (?) ... well at least when array-editing.
So perhaps there would be some way to modify the array-drawing code to skip samples in the drawing process and only the minimum required to display the data?
The "2000" and "300" constants mentioned above should be automatically adjusting in a smarter way... and then manually adjustable a bit.
Mathieu Bouchard http://artengine.ca/matju