Re: glame 0.3 jobs

[Richard G. <ric...@st...>]

On Mon, 17 Apr 2000, Joe Navratil wrote:

> > - I dont know really what the "step" parameter is :/ - i.e.
> >   whats the formula of the number of returned samples from
> >   the from, to and step parameter? (I assumed n = (to-from)/step
> >   which isnt true unfortunately...)
> 
> Er.  "Step" right now is misleading -- "span" might be more accurate.  n =
> (to-from) * "step" -- I'm passing the number of points to be plotted per
> pixel displayed in that parameter, right now.
> 
> I can change that if it'd be easier to work it the other way around.

Now its ok, also you are probably right to change step to be a float.

> > - Requiring the callback to return the samples in one chunk is
> >   limiting - at least for most efficient use with the swapfile.
> >   So returning an array of iovec-like structures may be the way
> >   to go (see inserted comments in wavetest.c)
> 
> I didn't completely understand this -- I get the impression the data in
> the struct gliovec->data field might change without notifying the widget?
> That's fine, but it means that the widget is going to have to be
> recomputed each time it gets an expose (right now, it backbuffers & copies
> if it can determine that none of the data's changed).  Shouldn't be a
> problem, though.  I'll go look through the swapfile code and figure out
> what the "readv/writev" comment meant :-)

I'll cut&paste the example gliovec struct from the code for the guys who
dont look at code very often :)

 struct gliovec {
       gfloat *data;
       glong from;
       glong to;
       gint step;
 };

The idea is to be able to pass non-continuous wave data back to the
widget and to take the from/to/step parameters as a hint only.
So the wave widget requests [100, 23000] with a step of 17 and gets
back f.i. two gliovecs, one with [0, 15999] and a step of 16 and one
[16000, 31999] and a step of 32 -- this would allow caching of the
subsampled data from the swapfile in the callback without caring much
about position/zoom level. Of course we may not allow step to increase
from the hint and we may force the returned gliovecs to be continuous
between them and sorted. Oh, and either an end-marker gliovec is needed
or better pass back struct gliovec ** with a trailing NULL.

Also you may assume the wave data - once registered to the widget does
never change. So we need a gtk_wave_draw_delete_wave(idx).

I dont know if the gliovec stuff is worth it performace/complexity wise -
but we'll know as soon as we can test scrolling/zooming interactively
(hinthinthint... :))))

Richard.

--
Richard Guenther <ric...@st...>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/