Re: Gnome Libs 1.0.60 is out.



>  I use the AA canvas quite a lot, and find it to be much better than
>  "useable".
>  
>  Could someone list the know problems with the AA canvas?  (I didn't
>  see anything relevant on bugs.gnome.org.)

Not all stock canvas items queue updates and redraws at the
appropriate times.  This bug is masked by the fact that
gnome_canvas_item_set() brokenly queues a redraw of the item's
complete bounding box.  This is not the right thing to do, and may not
work if the item recomputes its bounding box until later.  It also
makes the canvas repaint a lot more than needed, making it slow.

All items need to queue a redraw of the appropriate area, not an
update, upon destruction.  I.e. they should clean up after themselves.

The ::update() method of item needs to look more closely at the passed
flags.  You can look at the GnomeCanvasPixbuf item for the correct
sequence of checks.

The way in which item bounding boxes are handled is inconsistent in
several places.  Some places think they are stored in world
coordinates, and some others think they are stored in canvas pixel
coordinates.  This makes zooming not work in some situations.

Partially opaque arrows in the line item in AA mode have an overlap
between the arrow polygon and the line shaft.  We have to generate a
complete vpath for the polyline and its arrows instead of splitting it
in pieces.

GnomeCanvasText is completely broken in AA mode.

GnomeCanvasWidget may still have redrawing/affine issues, but I have
not tested it.

Deriving from GnomeCanvasClass in AA mode is hackish because the
canvas->aa flag is set in gnome_canvas_new_aa() instead of being set
from a construction function or as a constructor object argument.

There are other performance issues that may not be specific to the AA
mode, but I'd prefer to look into those only until after things are
correct and working.  I'd like to use some of EOG's functions for
microtile arrays in the canvas.

I think that covers most of the major bugs.  The GnomeCanvasPixbuf
does these things right, I think, so you can look at it for a
reference of how items should be fixed.

  Federico




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