Re: How to properly clip a gnome canvas item during render?

[Bob Gibbs <GibbsRC npt nuwc navy mil>]

Jason,

	Sounds like mostly the same problems I ran into.  There's more than one
way to skin a cat.  Here is what I did.

On Wed, 2004-02-11 at 16:20, The Surprises wrote:
> Thanks for the response. I'm not positive, but doesn't the default group
> already send a clip_path into the update() handlers of it's canvas
> items?  

The default group passes NULL as the clip_path into the update method. 
The only way to get a valid clip_path in is to override a canvas item or
group.  None of the stock items use it.

> The problem is that I don't know how to use this clip_path to
> only create the SVP for the visible portion of the canvas item.  I need
> the x,y + width,height values of the visible portion of the canvas.  If
> you look at the algorithm right now, when an update is called, i do:
> 
> 1. create a new vpath
> 2. sweep across entire length in the x direction
> 2a.   compute line segment at given x (very slow because I have to go to
>       disk to get it) 
> 3  affine transform above vpath
> 4. gnome_canvas_update_svp_clip
> 

It is true, that update is not called when you scroll.  The simplest
thing to do would be to take the scroll bars off you canvas and make the
scroll region the same size as the viewport.

The code fragment I sent in the last message will clip to the scroll
region, not the viewport. What I did was fairly complex.  I overrode the
GnomeCanvas  and calculated an extents_level based on a maximum zoom
factor and a maximum scroll region size.  Each time the user zooms in
out out by 5 or 6 times, the extents level bumps up or down and the
scroll region size is changed.  This way there is always some scrollable
area around the viewport but the area is never more than 5-6 times
larger than the viewport.  You can see this at
http://sourceforge.net/projects/geocanvas

> 
> 2a is really slow since I have to go off to disk to get the information.
> Once the svp is created, the transform and render is very fast.  Even if
> I implement caching, I'm still doing too much work since I really only
> need to create an svp for the visible area.

It is probably not a good idea to go to disk during your update, as the
GUI will freeze until this is done.

> 
> One potential problem that I may have run across is the update() method
> does not seem to be called when I scroll portions of the gnome canvas
> item in and out of view.  It only is called when the x, y, width, or
> height of the canvas item changes.  If that is the case, then even if I
> figure out the above, it won't work because I can't guarantee an
> update() will be called when a new part of the item is scrolled into
> view!
> 
You could also create a viewport_changed signal by connecting to the
"value_changed" and "changed" of the H and V adjustments.  Keep reseting
a 1 second timeout.  When the user stops scrolling for 1 second, emit
the "viewport_changed" signal and do your updating.
> 
> 
> On Wed, Feb 11, 2004 at 06:10:40AM -0500, Bob Gibbs wrote:
> > Hi Jason,
> > 
> > 	If you only want to clip during the render stage there is a stock item
> > called GnomeCanvasClipgroup that you can use.  I found that this does
> > not really save on processor load as the render stage is relatively
> > cheap in terms of CPU time.
> > 
> > 	If you are trying to save CPU cycles you should clip in the update
> > stage.  I did this a while ago with moderate success.  I was using all
> > stock canvas items so I overrode GnomeCanvasGroup, set the clip_svp in
> > its update method, then the group item passed the clip path to all of
> > the stock child items.  This of course only works for anti-aliased
> > canvas it has no effect on the gdk canvas.  I'm not sure if it will help
> > but I have pasted the code into this message.
> > 
> > 	I had a lot of trouble with the SVPs.  For my use case I was drawing a
> > large number of very large polygons.  I would see various error messages
> > coming form the libart_lgpl library. Whenever the error messages came
> > up, the CPU processor time shot up.  You'll see calls to "perturb" the
> > vector path in various places.  By tweaking the amount of randomness in
> > this perturb function, the number if errors coming from libart can be
> > limited.  This has something to do with "numerical stability" of which I
> > understand nothing.
> > 
> > Regards.
> > Bob Gibbs