On Thu, 19 Sep 2002, Keith Packard wrote: > A question has arisen recently and we're hoping for some outside comments, > given the passage of time and somewhat unanticipated advances in modern > toolkits. > The idea was to make sure that existing application would still be usable > while the screen depth was switched -- emulating the desired visual with > the hardware would leave those "legacy" applications running in an emulated > visual while the "smart" applications reconfigured themselves to use one of > the currently accelerated visuals.
> Given that there is no sample implementation of this capability, and that > at least Jim and I aren't going to manage to produce one in the immediate > future, the question is should we eliminate this part of the RandR > specification so that the extension as a whole can demonstrate a complete > sample implementation and become a useful standard part of XFree86? > Eliminating this feature from RandR would mean that applications migrating > from one X screen to another would need to be able to adapt to the available > visuals, rather than anticipating that whatever visual currently in use > would be available in the target server. > > As both Gtk+ 2 and Qt provide very abstract rendering interfaces for > applications, (and GTK 2.2 supports moving between screens even between > dissimilar X servers) this is not a burden for migrating applications written > to either of these two toolkits, reducing the urgency of this part of > the extension. The burden would fall solely on legacy toolkit applications > which want to add migration capabilities (and the number of legacy toolkit > applications continue to decline). ls -l /usr/lib/libgtk-1.2.so.0.9.1 /usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3* /usr/X11R6/lib/libXt.so.6.0 /usr/X11R6/lib/libX11.so.6.2 -rwxr-xr-x 1 root root 1410465 Apr 18 02:18 /usr/lib/libgtk-1.2.so.0.9.1* -rwxr-xr-x 1 root root 7644546 Apr 17 00:06 /usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3* -rwxr-xr-x 1 root root 874476 Apr 19 04:12 /usr/X11R6/lib/libX11.so.6.2* -rwxr-xr-x 1 root root 306040 Apr 19 04:12 /usr/X11R6/lib/libXt.so.6.0* and I thought Keith was worried about the size of Xt ! I'd like to be able to move an app from my palmtop to the living-room screen or video wall. I think it will a while before palmtops have memory/storage to be able to use Qt. Legacy apps may be in decline, but I think they have plenty of life left. Are we really asking that apps such as xdvi and ghostscipt be ported to Gtk+/Qt ? > The other limitation would be that there would be no good way to share > typical PC hardware between pseudo color and true color applications. > Emulating pseuedo color operations on true color screens remains > impractical. Environments left with legacy pseudo-color dependent apps > would continue to run X servers in pseudo color mode without access to > reasonable true color visuals. We could still perform this emulation in > the server, but RandR provided the means to switch acceleration modes so > that a large pseudo color app could get reasonable performance while > wrecking the display of any simultaneously displayed true color apps. Although 8+24 overlay hardware support is very limited, PC hardware support for DirectColor isn't uncommon. I take it you intend to emulate PsuedoColor when DirectColor is available ? (Color-map flashing can be annoying, so I wouldn't object to a server flag which had to be set to enable PsuedoColor emulation.) > However, without some interest in the community for this feature along with > a reasonable commitment to helping with the implementation, it seems more > important to get the subset of the specification known to work deployed > widely rather than wait an indeterminant time for this final piece of the > original design to be completed. Please comment if you have an opinion. "Rotate and Resize" doesn't imply "Redepth", so I can't really object, but my interest in RandR has always been in the possibility of running legacy 8 bit apps on a 24 bit screen. I'm prepared to put some effort into a PseudoColor emulation, but my skills are such that I wouldn't be able to do it without pointers to get me started, and assistance when I get stuck, from someone like Keith or Jim. In practical terms, you are right, we should deploy the working subset rather than wait. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
