Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!argv From: argv@turnpike.Eng.Sun.COM (Dan Heller) Newsgroups: comp.windows.x Subject: Re: GC: how many is too many? Message-ID: <3817@exodus.Eng.Sun.COM> Date: 1 Dec 90 07:44:58 GMT References: <4509@titan.sw.mcc.com> <1990Nov28.222839.498@thyme.jpl.nasa.gov> Sender: news@exodus.Eng.Sun.COM Organization: O'Reilly && Associates Lines: 36 In article toml@ninja.Solbourne.COM (Tom LaStrange) writes: > In article <1990Nov28.222839.498@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) writes: > >What is the maximum number of GC's that can be cached on X displays > >on the Sun workstations and the DECstations? Interesting question. > >Is there an upper limit on the number of GC's that an X application > >should reasonably create? The "should" changs the semantics of your question. Your first question seems to be asking what the limit is. The second seems to be asking which is better: to use lots of GCs with lots of settings or use few GCs and use xlib functions to change attributes of the GC. MY data my be out of date, but when I was at Island and I ported their Write, Draw and Paint apps to X there was a definite performance gain using many GCs on -some- systems while the same design rendered a performance drain on others. The difference seemed to be whether or not the particular system can afford the network traffic involved in changing few GCs many times or whether it can cache many GCs effectively. My final solution was to #ifdef for one way or another. I made a high-level function that "got" a GC that had the desired attributes and, depending on how the program was compiled, it would either change one of a few GCs and return it, or it would return one of a large number of GCs that matched the requested settings. Now, this was back in the R2 and R3 days... I have been relying on toolkits lately to worry about this in my current apps :-}. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.