johnl@iecc.cambridge.ma.us (John R. Levine) (12/01/90)
I am writing what I think is a straightforward X application, which mostly
writes fixed pitch text of various colors into a rectangular widget, and
reads keystrokes and passes them back to the application. (Think of it as
a special purpose xterm wired to its application.)
About half the time when I type a keystroke, the X server clears the
window and sends an expose event that forces me to redraw the whole thing.
There isn't much of a discernable pattern, but it's fairly repeatable,
e.g. if I set up the window with certain contents and press cursor down, I
get the cleared window and expose every time I do it. This makes the
performance look dreadful, since I sometimes have to redraw the whole window
on every keystroke. I'm not using XtMainLoop, since this code is glued
into an existing application -- there's an event loop of XtNextEvent and
XtDispatchEvent inside the "get keystroke or mouse button" routine, but I
can't see how that should affect the server.
The server is Interactive's X11R3 VGA server 1.1 running on a Paradise
super VGA. My widget is written with the basic Xt toolkit, though I am
running the Motif window manager. The widget uses 10 colors, but it gets
its pixels at the start of the session and changes its GC as it draws text
in different colors. Other than setting the icon at startup, there's no
window manager interactions beyond what Xt does automatically.
Is this a server bug, or is there some arcane server interaction that I
am fouling up? I'm baffled.
--
John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl
"Typically supercomputers use a single microprocessor." -Boston Globeetaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/04/90)
In article <1990Dec01.065919.16258@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes: |> I am writing what I think is a straightforward X application, which mostly |> writes fixed pitch text of various colors into a rectangular widget, and |> reads keystrokes and passes them back to the application. (Think of it as |> a special purpose xterm wired to its application.) |> |> About half the time when I type a keystroke, the X server clears the |> window and sends an expose event that forces me to redraw the whole thing. |> There isn't much of a discernable pattern, but it's fairly repeatable, |> e.g. if I set up the window with certain contents and press cursor down, I |> get the cleared window and expose every time I do it. This makes the |> performance look dreadful, since I sometimes have to redraw the whole window |> on every keystroke. I'm not using XtMainLoop, since this code is glued |> into an existing application -- there's an event loop of XtNextEvent and |> XtDispatchEvent inside the "get keystroke or mouse button" routine, but I |> can't see how that should affect the server. |> |> The server is Interactive's X11R3 VGA server 1.1 running on a Paradise |> super VGA. My widget is written with the basic Xt toolkit, though I am |> running the Motif window manager. The widget uses 10 colors, but it gets |> its pixels at the start of the session and changes its GC as it draws text |> in different colors. Other than setting the icon at startup, there's no |> window manager interactions beyond what Xt does automatically. |> |> Is this a server bug, or is there some arcane server interaction that I |> am fouling up? I'm baffled. |> |> -- |> John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 |> johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl |> "Typically supercomputers use a single microprocessor." -Boston Globe This does not seem like a server bug at all. You need to supply more information, though. Which widget are you using? Is it a widget that you authored? Is it a widget that already existed? If so, which widget is it? It you wrote your own widget, it sounds like there is a bug in your widget. Are you using SetValues on your widget when a keystroke is pressed? If so, then the behavior you describe is not a bug. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776