> That's true, but due to the fact that the widget doesn't have the input > focus and thus doesn't get the keydown event. Please add > > case FL_SHORTCUT: > > just below or above > > case FL_KEYDOWN: > > to make it the identical handling and test again. This should work with > the 'a' key then (it does here). > Thanks. It can accept 'a' now. Just slow as before. And adding "Fl::focus(t);" gives the same result.
> What processor (speed) do you use? Is it a local or remote X server? If > remote, what network speed? For me it looks like an effect of queueing > draw "events" in the X server event queue, so that the keypress events > will be delivered and acted upon only after some (much) draw processing > (with X11 server communication). But that's only an educated guess. > CPU: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping : 10 cpu MHz : 2534.000 cache size : 3072 KB .. processor : 1 .. I use a local server on gentoo box: [ebuild R ] x11-base/xorg-server-1.6.5-r1 USE="ipv6 nptl xorg -debug -dmx -hal -kdrive -minimal -sdl -tslib" 0 kB > I could partly replicate your effects by moving the window around on a > Windows (Cygwin) X11 server. This moving of the window stops redrawing. > After releasing the mouse, I could see that the window update doesn't > act smooth as before, but "jumped" until it reached the end of the > buffered drawing queue. During this period it didn't react on key > presses, but when it reached the smooth state, everything was okay again. Thanks. It seemed that I met the same problems on a program which do penty of drawing. > > What happens if you change the delay from 0.001 to a much bigger value > like 0.3 or so? Please keep in mind that Fl_Double_Window drawing will > always be slower than Fl_Window drawing, and time critical usage should > probably use Fl_Window. > Thanks. I need to draw animation in real time. But it seemed that I can use fl_begin_offscreen(),fl_end_offscreen(),fl_copy_offscreen() + Fl_Window to replace Fl_Double_Window. By the way, why will Fl_Double_Window drawing be slower than Fl_Window drawing? Is it due to fl_*_offscreen() call? > Another point: > > IIRC you did probably install the window resize patch from an STR that I > don't recall now. That *might* be the source of (some of) your trouble. > I still hesitate to commit that patch because I don't know if this would > make much more X server communication for all WM's except FVWM. That > said, another useful test would be without that patch, and maybe with > another WM, but I don't know... > > Albrecht This problem exists on kde environment too. Yes, I have installed that patch before this post. It is pity there are still no differences found after I finally removed that patch. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
