I also had to add the 2.24 and 3.x columns in there so I have continued the
previous status from all other bindings.
If anyone out there sees their binding is out of date, please let me know and
I can update it accordingly:
http://www.gtk.org/language-bindings.html
the Ada row should
What hadn't ever been made clear is if real-world applications were
seeing performance problems caused by the dashed stroking. It sounds
like maybe you're on to one of those now.
To be fair, even though it's a justifiable use, that's an extreme
case - with the font I'm using, one tree row is
Nicolas, can you get another profile using Markku's patch?
Most certainly!
A couple of preliminary remarks.
I have observed a startup time increase of between 20% and 30%.
When scrolling, here is what I observed:
- when displaying the selected row, performance is as bad as
before
This describes an idea to improve the display performance of the
tree_views, based on the sources of gtk+-2.10.11, and suggests
possible solutions.
Consider the subprogram attached. It shows a simple tree_view
displaying a list_store (5000 columns and 50 rows containing
integers). The
[Thanks everyone for your answers]
There is a really simple answer to this: GtkTreeView is not a table,
it was not designed to handle views like this with 50 columns.
I'm not sure I understand this part: should I use a gtk_table to
display this kind of data? What is the preferred way to
Hello Carl al,
I'm personally interested in hearing more details about what your
motivation for sticking with 2.6 is. If it's performance concerns, (as
is the case with others I've talked to), then I should point out that
I'm personally very interested, and planning on fixing those
