In reply to Jesse Barnes post. I'm not on top of the finer details, being a consumer rather than a developer. I have the following queries:
1) Is the buffer flip to be synchronous in the hardware, or to be implemented as a software interrupt? 2) By fullscreen, do you mean covering one or all screens in a multi-headed display? 3) If fullscreen means covering an individual screen in a multi-headed display, will it be possible to have multiple simultaneous fullscreen tear-free applications? 4) Will non-fullscreen applications be tear-free? To be honest, the speed of the window manager is not a big issue for me. Tearing is. In production mode, efficient fullscreen output mode is desirable. In development mode, having the output into manageable re-sizeable windows is nicer. The only way I can see non-tearing non-fullscreen applications working is with triple-buffer. i.e. a kernel screen flyback interrupt copies a screen-full from the multi-headed working buffer to a plane buffer, schedules that plane buffer to be swapped upon the next flyback, and triggers approptiate returns from the application swap-buffer function calls. I assume this is triple-buffer because there is the large possibly virtual working buffer and also two plane buffers for each screen. However a fullscreen application should be able to override this on an individual screen basis, rendering directly into the non-output display plane, and scheduling it to be swapped upon the N'th flyback. Apologies for sounding preachy, I simply outline my own analysis and am wondering how it is possible for a window manager, which must output to a larger virtual space, could be regarded as a good candidate for double-buffering as you suggest. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
