Re: GdkSpan
- From: Owen Taylor <otaylor redhat com>
- To: Alexander Larsson <alla lysator liu se>
- Cc: gtk-devel-list gnome org
- Subject: Re: GdkSpan
- Date: 20 Nov 2000 14:11:01 -0500
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...
> 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.
> 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?
Sounds good - though use a typedef for the function.
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]