[Nautilus-list] Re: AA rectangles in non-aa mode + speedups

[Alex Larsson <alexl redhat com>]

On Sat, 26 Jan 2002, Darin Adler wrote:

> Overall, this looks great, and you have my OK to check in. But please read
> these comments first.
> 
> I am surprised that you define, but don't use, RENDER_LIBS. I assume that
> we're implicitly relying on gtk to drag in the Xrender and Xext if they are
> present, but if so, then we shouldn't even define RENDER_LIBS. Also, you set
> have_render to false, but then use have_xft. Because of that mistake, I bet
> it won't work right on systems without Xrender.

Ooops. This is all a mistake.
 
> You should kill that FIXME in start_rubberbanding. All you need to do is set
> errno to 0 ahead of time, and then if it's non-zero afterward, make
> fill_color be the default color.

errno doesn't work. You have to pass an address for endp and see if it is 
the same as the passed string. errno is only usefull to detect overflow.
 
> I still don't understand exactly why the old behavior of re-raising the
> rubberband was a problem. Isn't gnome_canvas_item_raise_to_top a no-op if
> the item is already on top? If not, isn't the simplest fix to check for that
> case in GnomeCanvas rather than adding the logic here? I agree for the case
> where icons are raised, it's nice to raise them to the exact right level,
> rather than raising them to the top and then putting the selection rectangle
> back on top, but it doesn't seem like that would normally happen during
> rubberbanding. What do you say?

I did check in the shortcut for gnome_canvas_item_raise_to_top(), but that 
is not enough. When you rubberband over icons they become selected, and 
selected items are raised. Since they are then raised over the selection 
rectangle the selection rectangle timeout had to keep raising the it all 
the time. Even with the shortcut in gnome_canvas_item_raise_to_top() this 
makes the whole selection rectangle redraw everytime something was 
selected.

/ Alex