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

[The Surprises <thesurprises1 comcast net>]

On Thu, Feb 12, 2004 at 06:35:46AM -0500, Bob Gibbs wrote:
> Jason,
> 
> 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.
> 

Well I have to go to disk to get the data, it isn't stored in memory
(large AVI files).  Will eventually have a caching solution so you would
only pay for the initial load.

> > 
> > 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.

This sounds like a workable option.  Thanks for the suggestion.
Couldn't I also capture button_press/release on the scrollbar?  When the
mouse button is released I could emit the new signal.

Does your application handle drag-n-drop by any chance?  I sent another
request on this list for help with apparent issues with the gnomecanvas
and gtk's dnd capabilities.  They don't seem to work well together.

Thanks again
Jason