[Gtk-sharp-list] Tips for drawing quickly

[Rafael Teixeira]

In your boots I would look at the code for an actual GTK+ spreadsheet
implementation (like gnumeric or gtksheet) to see how they deal with
the performance problem.

I'm not aware of any GTK# Spreadsheet so far.

Also, for simpler needs, I think using a treeview with some custom
cell functions is enough, but currently GTK# has some trouble in that
as support for GInterfaces isn't in place, AFAIK.

:)

On 5/19/07, Aaron Oxford <aaron at hardwarehookups.com.au> wrote:
> Hi all,
>
> I have a very large, very important custom control in my application
> that is basically a big grid of numbers and words. The best way you
> could think of it is as a big spreadsheet. It has the usual things
> like selecting regions and what-not going on. The problem is it has
> to draw a lot of text (character by character, no less) and it's too
> slow to update.
>
> I have little experience with these sorts of things except in just
> making them go. This control is *really* sluggish though. I'm hoping
> this isn't just a side-effect of GTK, but in any case I'd really
> appreciate any tips on making things go faster. My other control
> (which is more like dragging boxes around on a canvas) is a bit jerky
> at 1280x960, but not unbearable. It seems that without double
> buffering, the updates are far faster. Is there a framerate setting
> somewhere? :-)
>
> I'm using the Gtk 'native' libraries under Windows, not the Gtk#
> implementation of System.Drawing. Is this inherently slower/faster?
> What about under Linux?
>
> Is there a way to make Pango do monospaced layouts (without
> restricting me to monospaced fonts)? I've done some experimentation,
> and I can increase the speed significantly by avoiding this excessive
> use of DrawLayout and using a cache of images to draw text. Is this
> the sort of lengths I should be going to or are there better ways to
> accelerate updating custom controls and/or draw a spreadsheet-like control?
>
> Could I for instance compose the appearance in a buffer, perhaps
> saving some time using image manipulation rather than completely
> recomposing the image on every update? That would be a lot of work
> and I could only attempt it if I knew it would pay off.
>
> Thanks in advance for any advice,
>
> Aaron.
> ---------------------------------------------------------------------------------
> Aaron Oxford   -   aaron+hardwarehookups .com .au
> Director, Innovative Computer Solutions (Aust) Pty. Ltd.
> 49 Maitland Rd, Mayfield, NSW 2304 Australia
> http://www.ic-solutions.com.au
> Developer, SourceForge project VioLet Composer
> http://sourceforge.net/projects/buzz-like
>
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>


-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw