gtk_paint_string future

[Matej Knopp <knopp users sourceforge net>]

Hi,

I'm writing an application and have chosen Gtk+ 2.0 for the gui. During
the programming I came to a very significant problem. The main window
consists of a pane with GtkTextView and GtkTreeView. The text view is
fine but the tree view almost made me abanon Gtk. It has 12 columns
(text) and after it's filled working with the app turns to be a pain.
Some experimentation showed the reason: GtkCellRendererText (and Pango).
Resizing the window, moving the pane or resizing columns was so delayed
that the app was absolutely unusable for production. I like pango and
the way it works but computing unicode layout and painting it so many
times was a too big deal even for duron 850. So I decided let unicode be
a wrote my own simple text renderer that converts unicode to 8 bit local
enc. and draws it with gtk_paint_string. It works suprisingly well.

So my question is: How long will the gtk_paint_string be in Gtk+?
I know gtk_paint_string is deprecated but it seems to be the only thing
that can make my app usable. Can I count on it in future? 
I also know that with gtk_paint_string there's no bi-di, antialiasing,
etc. but I'd give all these for fast text output.

I've also some comments on GtkTreeView. I think there are some further
possible optimizations. I'm not a Gtk+ hacker nor completely understand
GtkTreeView details. What I know is that it does complete repaint on
widget resizing and column resizing. The scrolling is OK since it's
(AFAIK) hw->hw blit. 
Now about widget resizing. I know this bit of work but it should be
possible to copy the part of widget before resizing (I'm not quite sure
about this...) and just update the rest. This would be cool in my case
when the View is in a pane.
The column resizing repaints the whole widget too. IMHO in most cases
the part to the left of resized column could stay unchanged, the resized
column has to be redrawn and the part to the right could be just copied
(moved). (HW->HW are most probably accelerated and this should be faster
then computing the layout and drawing it.

That's all, no more whinning :)

Cheers,
-matej