cheung@titan.sw.mcc.com (Po Cheung) (11/29/90)
What is the maximum number of GC's that can be cached on X displays on the Sun workstations and the DECstations? Is there an upper limit on the number of GC's that an X application should reasonably create? Thanks much, Po Cheung cheung@mcc.com
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (11/29/90)
In article <4509@titan.sw.mcc.com> cheung@titan.sw.mcc.com (Po Cheung) writes: >What is the maximum number of GC's that can be cached on X displays >on the Sun workstations and the DECstations? > >Is there an upper limit on the number of GC's that an X application >should reasonably create? > Toolkits such as Motif may have as many as a dozen GCs per widget; top shadow color, bottom shadow color, default font, foreground color, background color, etc. Multiply by the number of Widgets in a "typical" application; ours have > one hundred, then multiply by the number of applications running; two or three dozen. -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov Good girls get to go to heaven, but bad girls get to go everywhere!
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (11/29/90)
|> |> Toolkits such as Motif may have as many as a dozen GCs per widget; |> top shadow color, bottom shadow color, default font, foreground color, |> background color, etc. Multiply by the number of Widgets in a "typical" |> application; ours have > one hundred, then multiply by the number of |> applications running; two or three dozen. |> |> -- This is only partly True. Widgets using XtGetGC share their GC's. You might be suprised to find out there are probably less than a couple dozen per application using XtGetGC (I am assuming that the MOTIF widget set uses XtGetGC). -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (11/29/90)
In article <2933@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: > >| kaleb@thyme.jpl.nasa.gov (That's me) wrote: >|> Toolkits such as Motif may have as many as a dozen GCs per widget; >|> top shadow color, bottom shadow color, default font, foreground color, >|> background color, etc. Multiply by the number of Widgets in a "typical" >|> application; ours have > one hundred, then multiply by the number of >|> applications running; two or three dozen. >|> > >This is only partly True. Widgets using XtGetGC share >their GC's. You might be suprised to find out there are probably less than a couple dozen per application >using XtGetGC (I am assuming that the MOTIF widget >set uses XtGetGC). >-- Only partially right. Having just traced through widget creation in searching for a memory leak, I felt marginally qualified to answer the original question. I went back and verified. An XmForm has four GCs, each different: e.g. background_GC = 0x15b8c0 highlight_GC = 0x15bba8 top_shadow_GC = 0x15b9b8 bottom_shadow_GC = 0x15bab0 True, most widgets share share these GCs. Additional Widget types add additional unique GCs. e.g. XmPushButton has the following additional GCs: normal_GC = 0x15e6e8 insensitive_GC = 0x15e948 and: fill_gc = 0x15f400 background_gc = 0x15f4f8 These four appear to be shared among all pushbuttons. I could go on ad nauseum about each widget type and its corresonding unique GCs that it has but I won't. It wouldn't take much, using the various Motif Widgets to reach a good sized number of GCs. Add to that an environment such as ours which features a combination of of applications using Xaw, Motif, Homegrown, and possibly OpenLook, each adding to the score of GCs. On the client side, the number of GCs would be limited to system RAM, and available swap space. Since GCs aren't really that big, you could probably get a lot of them. All this of course dodges the issue of server side GCs. If I can make presumptions based on the level of cacheing elsewhere in X, it may be safe to say that the server caches like GCs, such that many instances of the same application would result in only one of each type is made by the server. It would be interesting to hear from someone in the consortium any thoughts they might have on the topic. Anyone care to comment? -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov Good girls get to go to heaven, but bad girls get to go everywhere!
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (11/30/90)
> ... (I am assuming that the MOTIF widget set uses XtGetGC). ...
It uses it everywhere it possibly can (and that means everywhere that I
know of).
-----------------------------------------------------------------------
Benjamin Ellsworth ben@cv.hp.com
All relevant disclaimers apply.
-----------------------------------------------------------------------toml@ninja.Solbourne.COM (Tom LaStrange) (12/01/90)
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? > >Is there an upper limit on the number of GC's that an X application >should reasonably create? > Toolkits such as Motif may have as many as a dozen GCs per widget; top shadow color, bottom shadow color, default font, foreground color, background color, etc. Multiply by the number of Widgets in a "typical" application; ours have > one hundred, then multiply by the number of applications running; two or three dozen. I haven't looked at the source for Motif but I would find this very suprising. The OI toolkit, which does a pretty good motif emulation has a grand total of 2 gc's (I think). -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,sun}!stan!toml Longmont, CO 80501
argv@turnpike.Eng.Sun.COM (Dan Heller) (12/01/90)
In article <TOML.90Nov30112458@ninja.Solbourne.COM> 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.
mouse@LARRY.MCRCIM.MCGILL.EDU (12/03/90)
> What is the maximum number of GC's that can be cached on X displays > on the Sun workstations and the DECstations? It depends on the server. The MIT sample server does not cache the things in hardware (all drawing is done by the main CPU scribbling on the framebuffer), so the only limit is memory: each GC you create corresponds to a structure allocated in dynamic memory by the server. If the server *does* take advantage of specialized hardware, all bets are off - it depends entirely on what the hardware can do and how the server uses it, though it is unlikely that the overhead per GC will be *less* than for the sample server. > Is there an upper limit on the number of GC's that an X application > should reasonably create? More than one per drawing operation performed is probably excessive :-) I wouldn't worry about it. If the application creates more than about a dozen I'd start wondering what's going on that it needs so many; if you think you want more than ten or so you are probably going about something the wrong way. (I can't give any definite number because there is no sharp line between "OK" and "too many". This estimate of about ten or fifteen as a point at which you should start wondering if you're doing things wrong is just a feeling, not a Rule.) This number I'm referring to is the number of GCs you actually create, not the number of conceptually different GCs. (They're not the same thing because many conceptually different GCs may be implemented identically, or perhaps may be implemented as one GC which keeps getting changed.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu