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.
-- FAReceived on Mon Feb 27 04:15:14 2006
This archive was generated by hypermail 2.1.8 : Mon Feb 27 2006 - 04:15:14 EET