At Wed, 3 Jun 2015 16:46:09 -0600, William G Hatch wrote: > Its main problem currently is that it spends a lot of time drawing. I > am using a canvas% and I override its dc%'s on-paint to get the contents > and then draw them on screen. I call the refresh method to queue a > re-paint whenever I get new input. If I, say, start up vim and start > writing in it, my input lags behind as it spends all its time > repainting. Are there some good practices for drawing stuff quickly? > > I was also wondering, before I start searching and grepping all over, if > someone who knows can point me to where I can see how drracket formats > the contents of its text panes (IE adds color, etc). Whatever it's > doing seems to be good, so perhaps I can leverage something there.
FWIW, your terminal seems much more responsive to me if I remove the `on-paint` call in `on-char` (since the terminal callback queues a refresh if any is needed, I think). DrRacket uses the editor classes that are described here: http://docs.racket-lang.org/gui/editor-overview.html That editor refreshes only part of the window when it can. For example, it's often easy to repaint only the current line where editing is happening. Redrawing only part of the screen means not calling `refresh` and instead drawing into that part of the canvas directly (but always drawing the whole canvas in a `refresh`-triggered `on-paint`). Use `suspend-flush` and `resume-flush` to avoid flicker while drawing outside of `on-paint`. > My other biggest issue right now is getting the child processes to > register window size changes, and I'm not sure whether it's a problem > with how I'm setting things up with the child or with how I'm sending > the resize signals through the parent. It's all through FFI calls into > the black box of ioctl, so it has nothing to do with racket, but if any > of you have tips for that, I would also appreciate it. But related to > that, I have some C constants hard coded right now in racket for the > FFI. Is there a way for me to get them out of the C header file so it > won't just break if/when the header changes? No idea on the ioctl issue, but you may have to run a C program to extract constants from header files. Probably you don't have to worry about numbers changing for a given platform, though, since the numbers get embedded in executables and OS changes usually avoid breaking existing binaries in that way. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
