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

[Bob Gibbs <GibbsRC npt nuwc navy mil>]

On Thu, 2004-02-12 at 13:53, The Surprises wrote:
> 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.

That would probably work.  The scrollbar and the adjuster are separate
widgets so you might have to dig a little to get the button release.

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

I've never used drag & drop.

> Thanks again
> Jason