Re: GdkSpan



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.

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.
 
>  - Would the 'GList *' return for gdk_region_span_intersect() better
>    be done as a func/data foreach? [ again, a question of usage pattern ]
> 
>  - It seems a bit inelegant/inefficient to have to do the walk through
>    the entire region again in the case of complex intersection, though
>    I suppose it is a pretty uncommon case.
>
>  - gdk_region_span_simple_intersect () should take two GdkSpans - one the 
>    input; one the output, and then work properly if they are the 
>    same.
>   
>    This is more simimlar to the way, say, gdk_rectangle_intersect() works.
> 
>  - The names aren't very natural sounding - while writing the above
>    I kept having to refer to the patch again for the names - how about:
> 
>     gdk_region_get_span_intersection_simple ()
>     gdk_region_get_span_intersection_list ()

A foreach func/data would match the usage pattern much better and make
this much cleaner. Then the need for the _simple case is removed too.

gdk_region_span_intersection_foreach(GdkRegion *region,
				     GdkSpan *span,
				     void (*func) (GdkSpan *span, 
                                                   gpointer data),
                                     gpointer data);

How about that?
 
>  - Since these are new public API entry points, they need documentation
>    comments.
 Sure.
 
/ Alex






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