On Thu, Jun 04, 2015 at 07:20:27AM -0600, Matthew Flatt wrote:
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).
Aha! Thanks, I didn't realize that was there. I was sprinkled a few of
them around when I was first figuring out where things needed to be
redrawn, before I learned about 'refresh'. I missed that one when I was
removing them.
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.
