Re: gtk_paint_string future

[Daniel Elstner <daniel elstner gmx net>]

Am Mit, 2002-06-05 um 21.21 schrieb Matej Knopp:
> 
> 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.

I just can't stand it.  That's so damn egoistic.  Yes, I honestly hope
others will be able to help you with the performance problems.  But
performance reasons just can't be taken as an excuse for not using
Unicode.  Did you realize that most people on this world speak languages
which cannot be represented in an 8bit encoding?

> 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.

It would be much better to ask how you can make the Pango version
faster.  I suspect it *might* a problem on your side, a Duron 850 is not
slow enough to render your app "unusable".

--Daniel