Re: Future features (was Re: Discussing issues)

On Wed, Apr 16, 2003 at 10:06:01PM +0100, Alan Hourihane wrote:
> On Wed, Apr 16, 2003 at 03:59:08PM -0400, Havoc Pennington wrote:
> >    This is something I was trying to quickly address with the DAMAGE
> >    extension I posted a while back. The reply I got on that extension 
> >    was from Keith and he said my extension shouldn't be included 
> >    because his bigger-picture changes would provide the same
> >    functionality more generally.
>  
> O.k. Is Keith still pursueing this Havoc ?

I assume so, but haven't asked.

Something fully general that said "take this region of screen, scale
it by factor N, and draw it to this drawable" certainly sounds nicer 
than the damage extension, I can't argue.
  
> There are other issues with hotplug too. In the case of multiseat - i.e.
> multiple Xservers running on the same machine with different graphics
> hardware and utilizing different keyboards & mice. If a mouse gets plugged
> in, which Xserver gets ownership of the device ? There needs to be a policy
> manager that allows new hotplugged hardware to be connected (or offered)
> to the Xserver.

I could envision that being part of a general "device tracker" library
of some kind. If you wanted to have a running service that was a
"device manager" then d-bus is a nice solution for talking to such a
service, but you could probably also do something with lock files.
  
> If the keymap is part of GNOME, I can't see the reason for including it
> in X. Doesn't the xkb keymaps that already exist in X fit your current
> bill anyway ?

I'm not sure. As I said I don't understand this issue. ;-)

The reason I don't think it belongs in GNOME is that these various
applets (there are also some in KDE etc., not just the GNOME one) and
also equivalent command line tools or whatever really should be
sharing this information.

Doesn't make sense to me for the definition of a Swedish keyboard to
live in a GNOME applet, in short. It seems like it should be in
Xkb. Maybe it is, I hope so.

> GPL code won't make it into XFree86 at all. That's why xf4vnc exists. 
> There are extra things you can do when your inside the Xserver that I
> currently haven't put too much thought into if the interface lived on
> the client side. I have suspicions that performance wouldn't be nearly
> as good, due to events being generated on every damaged region
> update.

Yeah. I'm curious what performance would be like with Xvfb writing to
a shared mem framebuffer, with libvncserver reading the damage region
from there. (Not polling for changes, just reading what's necessary.)

Another thing you could do, if you had the thumbnail/magnify
extension, would be to say "thumbnail at 1.0 scale factor to a shared
pixmap" and read from there. One more data copy than the Xvfb solution
though.
 
> >  - Double buffering that spans multiple windows, specifically the
> >    window manager frame and the application inside it. Some mechanism
> >    for WM and app to coordinate when to pop the buffer and draw to the
> >    screen.
> > 
> >    Within a single X window, a server-side damage region and backing
> >    store extension might be interesting if it were more efficient - we
> >    currently do this on the client side for GTK+, but could use a
> >    server side feature when available if it offered advantages.
> > 
> >    The multi-window case is the one that can't be done client side
> >    right now, though.
> 
> I'm not too sure what your getting at here, can you elaborate a bit more ?
> There is the double buffer extension (which I haven't looked closely at)
> which maybe we can utilize. I know the hardware drivers don't interface
> into this extension at all yet. 

I looked at the double buffer extension at one point, I don't remember
the details but I concluded it wasn't useful here.

The most noticeable instance of the problem to be solved is simply
that if you opaque resize a window, it looks pretty bad.

There are three reasons:

 1. The WM frame repaints/resizes and client repaints/resizes 
    are out of sync. This is made much worse because the 
    server scheduler starves the client.

    I have a protocol using XSYNC that does 1 WM repaint for 
    one client repaint, with toolkit support. That addresses
    this problem adequately.

 2. Once you do 1 WM repaint per 1 client repaint, they still don't
    repaint at the same time. More visibly, they don't *resize* at the
    same time. This is what double buffering the frame-client
    composite would fix.

 3. Some clients/WMs just repaint too slowly. This isn't X's 
    fault.

You also see this problem to some extent inside an application window;
if it has lots of buttons and each one is an X window, you can see
those move one by one. This is less of an issue in some newer toolkits
that don't use many subwindows anymore, but pretty visible in GTK+ 1.2 
for example, and still visible in certain GTK+ 2 windows.
 
> >  - Earlier on this list we had a thread about how it was hard to do
> >    smooth animation. I can't find the link now, but some general
> >    thinking in that area would be useful.
>  
> More information would be useful.

This thread is what I was thinking of:

 http://www.xfree86.org/pipermail/forum/2003-March/000590.html
 http://www.xfree86.org/pipermail/forum/2003-March/000647.html
 http://www.xfree86.org/pipermail/forum/2003-March/000664.html

> >  - Some of the freedesktop.org specs such as EWMH could use broader
> >    review and feedback.
>  
> Post a link so I know I'm looking at the right thing.

Some X-related stuff:
 http://www.newplanetsoftware.com/xdnd/
 http://www.freedesktop.org/standards/wm-spec.html
 http://www.freedesktop.org/standards/xembed.html
 http://www.freedesktop.org/standards/clipboards.txt
 http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/
 http://www.freedesktop.org/standards/xsettings.html
 http://www.freedesktop.org/standards/clipboard_extensions.txt
 
> 'make World' and then 'make DESTDIR=/yourpath install' is all you need to do. 
> 
> This shouldn't mess up anything and will install everything from the build
> into '/yourpath'. Create a new XF86Config file to use this new path, and
> off you go.

Thanks.

Havoc