On Mon, Feb 27, 2006 at 01:16:17AM +0200, Jussi Laako wrote: > On Sun, 2006-02-26 at 20:38 +0100, Albert Graef wrote:
> > Canvases give you much more than just rendering. They also manage the > > graphical objects that you created and, if anything changes, rerendering > > the changed parts happens automatically. > > That's usually bad and undesirable for any real time graphics rendering, > like audio UIs often are. For example with proper interfaces I can now > get full screen scrolling spectrogram at 50-100 fps without huge CPU > load. Correct. Having done a lot of this stuff in earlier lifes, my conclusion is that the right way to organise redrawing, scrolling, zooming etc. depends a lot on the sort of data you want to display and how it is modified either 'from within' or as a result of user interaction. I just can't imagine there could exist a single model that would handle even a small selection of the situations I've encountered efficiently. Every abstraction is based on some assumptions and I've seen them break down time and time again. When using X, you have a fundamental choice between drawing directly to a window or to a pixmap. In the first case you must be prepared to refresh anything at any time, and be organised to do this effeciently. In the second case X will take care of refreshing newly exposed parts, but you are using a limited resource (if the pixmap has to remain in graphics memory for speed). I guess most canvases take the lazy (2nd) route. -- FA
