[gsharp-devel] redraw buglets

Robert Strandh strandh at labri.fr
Fri Jul 16 12:21:26 UTC 2004

Christophe Rhodes writes:
 > The new redrawing behaviour is very noticeably much better -- for
 > those who haven't tried it yet, my understanding is that it means much
 > less needs to be redrawn for each keystroke.

I think it is the same.  It is just that everything is drawn in a
pixmap before sent to the pane.

 > There is still visible flicker in the two right-hand panes, though.

Ah yes.  Those should be done the same way.

 > As I understand it, the top right hand pane (the input state) should
 > only need to be redrawn if the input state changes, but apparently
 > it's being redrawn on every command.

True.  It does not cost very much to always redraw it (in case the
command was one to change the input state), but yes, it could be
optimized by using pane-needs-redisplay (or something like that).

 > Similarly, the current element pane is redrawn rather often;
 > admittedly the current element changes more often than the input
 > state, but maybe the staff lines don't need to be redrawn each time?

I am sure there are many optimizations to implement, but I am not sure
it will make a big difference.  I would like to know what makes
redrawing an entire page of the score around a second.  Once I find
that, I could try to figure out how to speed up the entire thing.  At
this point, I do not know whether it has to do with Gsharp, McCLIM, or

 > In addition, there seems to be an unrelated bug there: the red dot
 > representing the notehead is not redrawn if the gsharp window is
 > covered up and reexposed.

OK, that's strange.  I'll try to look into that. 

Robert Strandh

Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.

More information about the gsharp-devel mailing list