On Tue, 25 Jun 2002, Lukas Molzberger wrote:
> 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'm not really sure about that. I've seen the effect that Owen
described and it's always seemed rather subtle to me. I could never
see appreciable slowdowns unless I sat there resizing manically for
a few seconds. Maybe Owen has some pathelogical cases that can
show it quicker, but I still don't think it's the primary cause of
opaque resize slowness. There are alot of apps that redraw everything
whenever they get a ConfigureNotify event. That's a problem.
I have written sample apps that do not have problems with opaque
resizes in my environment.
>
> > 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.
The X-server would have to block until the refresh. It might not even
be scheduled at that time meaning you could miss refreshes. The performance
impact would be profound. The guys who have tried to synchronize video
overlays in software when the hardware doesn't double-buffer the swaps
for them know what I'm talking about here.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
