Re: canvas painting

I've been thinking of an ellegant way to do it.

In the case of Micheal, I don't see why you don't draw the two circles 
using a XOR pen on the canvas (see the scribble example in the gtk 
tutorial), that would definitely save you a lot of drawing (you wouldn't 
have to do it from the canvas). This can be easily done on top of 
gtkextra, and not from "inside".

On the other hand, I know that most of the drawing is spent in the text. 
A solution that could be implemented in gtkextra-3 (three!!), could be 
to use a transparent pixbuff to store each empty plot, and then using 
gdk-pixbuff to display them on the canvas. However, notice that this is 
a generic solution, it would only work for real-time simulations, but 
not for printing (then you have to redraw the whole thing). I just came 
up with a solution, but I don't have time to work on it right now:
Design a new gtkplot subclass, say gtkplotrt (for real-time). You would 
only have to implement the backing pixmap part, and the drawing can be 
done by the parent (gtkplot) class.

Saludos,
<ADRIAN>

Michael Noble wrote:

>>On Wed, Dec 15, 2004 at 01:16:08AM -0800, Al Hooton wrote 
>>
>>	I'm not asking for a new feature here, just tossing out a question/idea
>>to discuss: Would it make sense to add some kind of mechanism to
>>canvas/plots so that axes only have to be redrawn when necessary?  As
>>you point out, it is certainly possible for the app to cache the values
>>in an array and avoid recalculating them, but this still leaves the
>>canvas & plot the job of repainting axes each time, something that takes
>>a lot of processor cycles too.
>>    
>>
>
>Al, I think you're on the right track, although the issue is more
>widespread than just axis redrawing, and so probably warrants a
>more general solution.
>
>For example, try plotting a million points, then laying down two circles,
>then moving the circles to new locations on the canvas.  Each move must
>be performed individually, and each erase/redraw operation induces a
>complete canvas repaint.  It shouldn't be hard to imagine how slow/choppy
>it can be, then, to make even the finest adjustments to circle/region
>positions when they are laid over million-point plots (which are not
>completely rare in my domain).
>
>I've ameliorated this to some extent (in my local copy of GtkExtra)
>with a number of performance improvements (which I hope to someday
>to find the time to post here), but the real issue seems to be that
>points (data) should be drawn upon one backing pixmap and decorations
>(axes, circles, etc) upon another.
>
>It's been a long time since I looked at the code, and I've never quite
>found the time to do this myself, but in principle this should be feasible
>and entail only a little extra code to:
>
>   - fabricate the extra backing pixmap at canvas creation time
>
>   - ensure the proper one is used when the respective graphics are drawn
>     (might be able to get away with changing only the plot/data objects)
>
>   - blit the decorative pixmap first, then the data pixmap, when
>     painting the canvas
>
>Otherwise the rest of the code might remain largely unchanged, as objects
>simply shouldn't care upon which pixmap they're drawn.
>
>Hopefully Useful,
>Mike Noble
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now. 
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>Scigraphica-gtkextra mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/scigraphica-gtkextra
>
>.
>
>  
>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/