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