Mark Vojkovich <[EMAIL PROTECTED]> writes:
> 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.
The behaviour where the client stops drawing completely is not
difficult to get with a moderately complex gtk+ 2.0 application and
the X server running without -dumbScheduler.
With -dumbScheduler, I can't get drawing to completely stop, but there
is definitely noticeable lagging. Compared to Windows, opaque resizing
really sucks.
I think this is what happens during opaque resizing (with gtk+):
(a)
1 window manager gets a mouse event.
2 window manager reconfigures client window and draws
frame
3 server draws frame and sends the configure event to
client
(b)
1 client reads all configure events
2 client relayouts widgets and resizes all windows
3 client normally redraws everything (although some widgets,
like the TextView, and in 2.2 the TreeView, are smarter
and only redraw newly exposed areas).
A gtk+ client often overflows Xlibs request buffer 30 or more times
during b.3 (a simple strace will confirm this), so the X server can
easily get scheduled during this [1], and get back in (a).
With the smart X scheduler clients that are getting input events have
their priority increased, and since during opaque resizing the window
manager gets input events and the application doesn't, the application
gets starved and it is possible to get stuck in (a) forever, which
looks as if the application has stopped drawing completely.
With -dumbScheduler we can still get stuck in (a) for a long time, but
not forever.
It would be an interesting experiment to make the window manger block
an an XSYNC counter after it reconfigures the application
window. Then, when the application finished drawing, it would increase
that counter. (It is possible to also block the window manager on a
timer, so it wouldn't be blocked forever).
[1] And this is probably the reason gtk+'s windows can get quite a bit
out of sync during opaque resizing.
> 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.
The X server doesn't even have access to the vsync interrupt, right?
As far as I know cards send an interrupt when they enter vertical
retrace, but the (linux) kernel doesn't pass it on to user space
applications. If the kernel did pass it on, maybe as a signal,
wouldn't that make the latency from the interrupt occured until the x
server was scheduled very small?
Why would the entire X server have to block? If the SYNC extension was
extended with a counter indicating vblank, then the window manager
could send "wait for vblank" requests itself before it moved a window,
and the server wouldn't have to block any other client.
S�ren
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
