Sat Oct 30 10:08:44 1999  Tim Janik  <timj@gtk.org>

	* ftest.c (toggle_auto_resize): added new auto_resize debug flag.
	* gnomeforest.c (sprite_ensure_vpath): auto_resize upon vpath changes
	to check requisition mechanism.

Sat Oct 30 09:48:15 1999  Tim Janik  <timj@gtk.org>

	* gnomeforest.c (gnome_forest_size_request): request a size that is
	big enough to fit all visible sprites in it. this is only usefull for
	static forests, for animated ones, users should specify usize.
	NOTE: we do *not* queue resizes upon insertion of new sprites, simply
	because for animated forests, people don't want that. so if you add
	new sprites to a static forest and want it to request a new size
	based on that, queue a resize on the forest.

	* gnomeforest.[hc] (gnome_forest_size_allocate): added expand_forest
	argument, so one can specify to center the forest within its allocation.

Mon Sep 13 15:58:42 1999  Tim Janik  <timj@gtk.org>

	* gnomeforest.c (gnome_forest_render): art_rgb_fill_run() takes the RGB
	values as 0..255, not 0..65535.

	* gnomeforest.c: draw the forest with widget->state and not always
	GTK_STATE_NORMAL, catch ::style_set and ::state_changed for this.

Sun Aug 15 06:47:06 1999  Tim Janik  <timj@gtk.org>

	* gnomeforest.[hc]:
	a sprite engine based on libart, implemented as a gtk widget.
	- the widget simply displays a libart-rendered buffer that is exactly as
	  big as its allocation, thus it implements double buffering.
	- it keeps two utas, one for the area that needs to be repainted (e.g.
	  due to expose events or queue_draw) and one for the area that needs to
	  be rerendered (due to sprite movement, showing or hiding).
	- screen display is actually done in two steps: first neccessary
	  regions are rerendered from render_uta. secondly, the screen is
	  updated from paint_uta (paint_uta will always incorporate render_uta).
	- the actuall rendering and painting is done from idle handlers only,
	  that way users can apply multiple transforms to the sprites, and their
	  vpaths and svps get only updated shortly before the renderer needs
	  them. (i'll make the priorities configurable at some point, e.g. a
	  demo widget will want to use low priorities, while a game will
	  probably want high priorities).
	- collision detection (CD) happens when the sprite svps got updated.
	  the current libart intersection code is pretty slow (and buggy),
	  especilly when its "collinear" warnings are triggered.
	currently debugging code is left in place and can be activated through
	setting of struct _GnomeForest flags:
	shade_svps - draw the svps that are used for uta computation and
	             intersection with 0xffffff80 on top of the sprites
        show_utas  - show the computed uta rectangles (white outline with black
	             cross, this actually gives a nice impression on how smart
		     and effective utas actually work)
        disable_cd - disable collision detection at all
	debug_cd   - print CD areas and mark the intersection points
					       

	* art_vpatho_pixbuf.[hc]: necessary libart additions:
	(art_vpath_outline_from_pixbuf): create a precise outline vpath from a
	pixbuf. it does not produce crossing vpaths or segments, but certain
	edge points may overlap.
	(art_affine_from_triplets): reconstruct the affine that transformed the
	three points src_triplet into transformed_triplet.
	(art_vpath_area): compute size of area embedded in a vpath (raph).
