3000 toggle buttons in a table? (was: Button Vs Toogle Button)

[Gus Koppel <gtk spamkiller bytechase cx>]

"Sailaxmi korada " wrote:

>   My application has to display around 3000 toggle buttons, in 178 rows of a
> table. It is taking almost 12 seconds to do so.
>
>   Can you help me out in reducing this time.
>   Here are the two steps that are consuming maximum time
>
>   gtk_button_set_label (GTK_BUTTON(drpentry_binbutton), "1");
>
>    gtk_toggle_button_set_active
> (GTK_TOGGLE_BUTTON(drpentry_binbutton),FALSE);

I refrain from asking who might be supposed to toggle all 3000 buttons.
I rather suggest you to do without standard widgets at all when it comes
to such an exorbitant number of toggles.

It's right that GTK+ gets rather slow if several hundreds (or more)
widgets are to be built and displayed. This is because each widget has
quite some overhead, regarding its numerous memory structures, internal
procedures and handlers and, last but not least, the layout calculations
of the table.

I rather suggest you to do some more work on your own for this rather
special application. Don't use standard widgets like GtkToggleButtons
and a GtkTable. If I had to manage 3000 toggles on screen, I would
simply use a GtkDrawingArea and manage the display and input handling of
those toggles on my own.

Monitor the visible height of the drawing area, divide it by 178, then
you have the average height of each "button". Do the same with the
width. Render the "button"s on your own, that is, perhaps draw a frame,
draw inside labels (you may use clipping for this), and define two
different appearances for the two states of the toggles, i.e. two
different background colors or different frame appearances.

You wouldn't need to connect thousands of widgets to their appropriate
handlers either (which would take quite some processing time and memory
as well) but rather simply monitor button press and button release
events within the single drawing area and calculate the pressed button
number by the given mouse pointer coordinates. Maintain a simple bitmap
(or bytemap) of 3000 entries, one for each button, to store and change
its current state.

If keyboard navigation inside the buttons field is required, you would
have to built it as well. However, in such a button matrix you could
achieve an even more comfortable focus navigation if you not only
support [TAB] and [SHIFT]+[TAB] but also the cursor keys for vertical
navigation. The number of rows you mention suggest that this would be
appreciated by users.

This way your button matrix would of course not be fully
GTK+-theme-compliant but I guess this would be much less of a worry for
you. This way you can achieve a practically instantaneous buildup
(accelerated by factors of 10 to 20 compared to genuine widgets). GDK
provides a fine set of drawing primitives for you.

In fact, you might also consider to derive a new type of widget from
your work, like GtkToggleButtonMatrix (not to be derived from
GtkToggleButton), which not only you could benefit from, if it comes to
similar projects in the future, but others could as well, if you decide
to publish your work.

Btw, on this high numbers of widgets you can certainly expect your
performance problem to be the same (or even worse) on most other
toolkits like QT or (especially) Java Swing. FLTK might handle this
significantly faster with its builtin widgets, but doing it the way I
suggested would still be the fastest, by far.