2008/1/11, pete shorthose <zenadsl6252@zen.co.uk>:
> > eg: from scroll-pane.c:
> > scroll_pane_draw_data_channel ()
> >
> >   d = ((sw_audio_t *)sample->sounddata->data)
> > [i*channels + channel]; on
> >
> OK, so good news: it should be stable, bad
> news: it should be slow. The main problem is
> that scroolbar refresh and redraw
> (scroll_pane_expose) is called every time with
> all sample to redraw and it's gtk_scroolbar
> feature. This is why I was starting to write
> sample cache.

i may have misunderstood what you meant by display
cache. i'll take a look at that patch.

No, I think You have understood it correctly. Display_cache is located in display_cache.[c,h] files and do the following things:
- compute min/max/avg/rms, etc.
- compute sinc/other interpolation (unfinished)
- cache above computations in memory (has some limitations)
- (in future) compute FFT

ardour uses some funky macros to do wave drawing.
presumably they are faster so that might be
something to look into.

General rule is to draw and compute as minimum as possible. With display_cache we can reduce number of computations, with smart backing store pixmap we can reduce number of drawings.

i can also enable backing store on all
widgets (xconfig permitting) to skip incidental
expose events too. assuming it's suitable for
rapidly updated windows. (i think qt4 does this

Good step.

it's pretty quick in operation here though. p4
mobile 2gig laptop. hardly the state of the art.


We have to remember that cairo drawing library is waiting to get full hardware acceleration in gtk.



Radosław Korzeniewski