Hi Mark, thanks for your reply. On Tuesday 25 June 2002 03:27, Mark Vojkovich wrote: > On Fri, 21 Jun 2002, Lukas Molzberger wrote: > > Hello, > > I'm using Linux and XFree for quite some time now and I'm a big fan of > > it. However, there is one bug that has always annoyed me. When I resize a > > window under XFree then it can take a long time until the content of this > > window is redrawn. > > This has little to do with the X-server. Many window managers do not > optimize window resizes well (they aren't compressing the events) and > many clients do not handle exposures very well.
That's possible and it might also be responsible for a part of resizing slowness, but I think that what Owen explained in his reply is exactly what I meant. > I don't think there's > much on the X-server side that can make up for that. > > > Another thing that I've noticed is that when moving a window from left to > > right or vice versa the window is split along a line and the upper part > > of the window is drawn at a slightly different position than the lower > > part. This splitting line is always at a different position. I think this > > happens because X doesn't synchronize with the horizontal screen refresh. > > X should wait until the screen refresh is finished before changing the > > frame buffer so that only a consistent picture is brought to the screen. > > In case I got something wrong here than I would like to apologize for it. > > Window moves shouldn't synchronize with the refresh rate because > of the performance penalty it would impose. All other rendering would > be suspended until the next retrace whenever you wanted to move a > window. Hmm, what I first thought about was to synchronize the double buffer swapping with the screen refresh, similar the way it is done in OpenGL. As far as I know most toolkits use double buffers and such a db swap is also very fast. However, I'm not sure if that would help when moving a window? But if window moves would be synchronized with the refresh rate why would all other rendering be suspended until the next retrace? I also don't think that there would be a large performance penalty, since the worst case delay time would only be 1/80 second. > This shearing effect can mostly be eliminated by sychronizing > your pointer sampling rate to the refresh rate. Just set you pointer > sample rate to 80 Hz and also your refresh rate to 80 Hz and you will > find that all mouse-driven operations will appear much smoother. OK, I'll try that. Thanks for the tip. > > Also, given that the X-server is a user-space app. Synchronizing > blits with the retrace is typically not possible on most hardware. > Cheers Lukas _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
