Re: GdkSpan



On 20 Nov 2000, Owen Taylor wrote:

> 
> Alexander Larsson <alla lysator liu se> writes:
> 
> > On 20 Nov 2000, Owen Taylor wrote:
> > 
> > > 
> > > Alexander Larsson <alla lysator liu se> writes:
> > > 
> > > > For my next checkin to GtkFB i need to do some generic Gdk changes. I
> > > > added a new type GdkSpan, and two functions that handle intersection these
> > > > with regions.
> > > > 
> > > > Is this patch ok? I'd also be very glad if someone (owen?) reviewed the
> > > > intersection functions, since these kind of functions are very sensitive
> > > > to boundary condition errors, and quite hard to test.
> > > 
> > > Hmmm, I'm basically OK with the addition, but some questions about the interface
> > > details:
> > > 
> > >  - How are you going to use these functions?
> > > 
> > >    It worries me a bit since the typical case is taking a graphics
> > >    primitive and breaking it into a set of spans. Taking those spans
> > >    and intersecting them one-by-one with a clip region is 
> > >    going to be _slow_ ...
> > 
> > They are used by the GtkFB rasterization code. Currently
> > gdk_region_intersect() is used instead.
> 
> Which may well be faster...
No. It takes each span, makes a rectangle of it with height==1, converts
it to a region, intersects that region with the clipping region and draws
the resulting rectangle.
  
> > How would you do it then? Consider a wide arc with dashes. Rasterizing
> > this to a Drawable using a GC with a clip region in GtkFB currently
> > generates the spans from the arc, then clips each span to the GC region.
> > 
> > Clipping the dashed arc to the clipping region first and then directly
> > rendering each span is just undoable. The intersection of the clip region
> > and the arc is far to complex.
> > 
> > Note that there can be "shortcuts" for certain primitives when the GC has 
> > a "simple" state.
> 
> I agree that generating spans and clipping them is the right thing to
> do. My doubts come from the fact that there the possibility of very
> significant optimization from having a routine that takes an array of
> spans in banded order and does the clipping on all of them at once,
> rather than clipping them one by one.

I see. I'll have to think about this.

/ Alex





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]