Re: slowness in getting events

[Dov Grobgeld <dov grobgeld gmail com>]

Since hex characters only has an alphabet of 16 characters, you can draw
these once into separate pixbufs, and then use gdk_pixbuf_copy_area() to
draw the prerendered characters to the screen. If you have the memory you
can e.g. create 256 two-nibble precomposed glyphs. I'm not sure how much
more efficient this is compared to the gtk/pango/freetype caching of text,
but it is worth a try.

An additional option is to only update your screen at some reasonable
interval, e.g. 5-10 times a second. Higher than that is hardly going to be
seen by the user anyhow. And if you are looking for exceptional behaviour
you may want to use other approaches like coloring the cells to indicate
that.

Regards,
Dov

2009/4/6 Efraim Yawitz <efraim yawitz gmail com>

> On Mon, Apr 6, 2009 at 2:00 PM, Michael Torrie wrote:
>
>
>    You might want to implement this hex dump display as a GtkTreeView
>    widget, which does lend itself better to displaying tabular data.  The
>    MVC mechanism by which the TreeView works means that the view
>    automatically updates itself as the model (your hex data) changes and
>    emits signals.  You an even have multiple views of the same data if you
>    need it.
>
>    There are also a number of custom widgets that implement
>    spreadsheet-style grids you can search for.
>
> Some more testing has made it clear to me that the problem I am having is
> not that I am not getting the events, but that gdk_draw_layout(), which I
> am
> calling many times per update, is too slow.  I found some posts from a few
> years ago that this was hundreds of times slower than XDrawString(), and I
> have verified that it is much slower.  Of course, XDrawString is much
> harder
> to use.  Does anyone have any ways of dealing with this?
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list