dcr0@GTE.COM (David Robbins) (10/12/90)
I have been given a small task: find a way to improve certain aspects of
the Motif 1.0 text widget. I am relatively new to Motif, and may have
missed some relevant discussion in this newsgroup, so bear with me. I am
hopeful that some of you out there have encountered the problems I need to
solve and can point to some good solutions.
The application I am dealing with puts up forms on a screen for the user
to fill in. These forms typically have 50-100 fields into which the user
might enter data. Each of these fields is implemented as a Motif text
widget. (You might question the wisdom of designing the application this
way, but we're stuck with it and we have to try to make it work.)
It works, in most respects. The one major problem at this point is the
performance of the beast. With 50-100 text widgets on a form, the
thing takes much too long to put the form up on the screen. I've spent
considerable time analyzing the situation, and aside from identifying other
ways to improve the performance somewhat, I am reduced to the following:
The Motif text widget makes a number of X server requests that I believe
to be unnecessary:
1) Every text widget uses the same pixmap for a cursor. As each text
widget is realized, it mucks with that pixmap. There seems to be a
lot of unnecessary work here -- if a single pixmap is to be shared
(which is quite sensible), then it should be shared in such a way
as to not require it to be updated in any way for every text widget
that shares it. This seems easy enough to do, but why doesn't Motif
do it?
2) I would like to be able to create a set of text widgets to use for
fields and be able to reuse them each time a form is displayed. I
would just have to update the widget's size, position, contents, and
one or two other resources. BUT, when I implement it this way, it is
*even slower* than when I create new widgets for each form displayed.
I observe that the reason this is so is that when XtSetValues updates
the text widget's resources *while the widget is unmapped* the widget
proceeds to send out a pile of X server requests! I claim that this
is *totally useless* since the X Toolkit explicitly provides a way for
automatically and optimally getting any necessary redisplay done --
*after* all resources have been updated. This also seems easy enough
to do, but why doesn't the Motif text widget take advantage of it?
I can make the observation that these really do not become performance
problems unless you have a large number of text widgets visible. With one
or two or five text widgets, the excess cost of such things is lost in the
noise. But when we do the same thing 50 or 100 times, small increases in
cost are magnified.
So, to make a long story short, I respectfully ask the following:
A) Have any of you encountered and solved performance problems with the
text widget? If so, please share what you can with me and the net.
B) Am I completely off the wall in thinking that I understand the problem?
C) To what extent does Motif 1.1 solve these and perhaps other performance
problems, particularly for the text widget? (I do not have 1.1, nor do
I expect to see it soon -- but if it answers my prayers, I may be able
to acquire it.)
D) Are the Motif developers aware of these problems?
I'll be happy to summarize for the net any useful responses I receive by
email, and of course you'll all see any responses that get posted.
--
Dave Robbins GTE Laboratories Incorporated
drobbins@bunny.gte.com 40 Sylvan Rd.
...!harvard!bunny!drobbins Waltham, MA 02254
CYA: I speak only for myself; GTE may disagree with what I say.marbru@auto-trol.UUCP (Martin Brunecky) (10/12/90)
In article <9873@bunny.GTE.COM> dcr0@bunny.GTE.COM (David Robbins) writes: >I have been given a small task: find a way to improve certain aspects of >the Motif 1.0 text widget. I am relatively new to Motif, and may have >missed some relevant discussion in this newsgroup, so bear with me. I am > >A) Have any of you encountered and solved performance problems with the > text widget? If so, please share what you can with me and the net. I had not only performance problems, but primarilly functionality problems. Things that were supposed to work and did not, and things that we needed but aren't there (overstrike mode, smooth scrolling -- oh, there's a lot to be said about scrolling, source limited to memory buffer only etc...). As we had a text widget based on Xaw R3 widget, we'w gradually evolved it ... so today I don't see any reason to go back and use Motif's one, based on archaic architecture from R2 intrinsics. > >B) Am I completely off the wall in thinking that I understand the problem? > Mhm. A don't think you are completely off the wall, but I am not sure you understand the magnitude of the problem. When I took over our text widget, I estimated 2 weeks to finish it. It took me 3+ month, and though I dropped the code from over 10,000 lines down to 5,000 lines, it was quite a frustrating period. >C) To what extent does Motif 1.1 solve these and perhaps other performance > problems, particularly for the text widget? (I do not have 1.1, nor do > I expect to see it soon -- but if it answers my prayers, I may be able > to acquire it.) Several people claimed significant DEGRADATION in 1.1 (I haven't received 1.1 yet [thanks, OSF-)] ). Primarilly caused by additional functionality, such as noncontiguous selection ranges (wrong term, I guess-). > >D) Are the Motif developers aware of these problems? > I am not quite sure if Motif developers watch this newsgroup. From the postings on Motif talk list, I estimate OSF has about 3 SQA people, about 2 engineers and the God knows how many managers -). I believe that the only think CONSIDERED by OSF are BUGREPORTS. Any suggestions here or on the motif-talk list are just whining. > > One thing that is necessary, really necessary, is a vastly simplified text field. I'v been told that Motif 1.1 will have a text field gadget,] but I haven't heard about it yet. In fact, I don't think that a gadget is a good thing here, since in absence of a window you have to put clip rects into GC, either having a private GC (much more expensive than a simple window), or you have to constantly load/remove clip rects - lots of overhead again. Such a text field would have much smaller instance, as the "big" items such as line table and lots of the scrolling support can be nuked out. It may share the same sink/source objects with the "big brother", as those (if correctly implemented) may have fairly small instances. The tough task is how to inherit what's good in the "big" Text widget, so that the Motif's typical code duplication is avoided. [Few weeks ago I offered OSF to mail them the code for my text widgets hierarchy, just to look at different optimizing techniques used, but nothing came back. They probably know better.] -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
dbrooks@osf.osf.org (David Brooks) (10/13/90)
In article <880@auto-trol.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes: > Several people claimed significant DEGRADATION in 1.1 (I haven't received > 1.1 yet [thanks, OSF-)] ). Primarilly caused by additional functionality, > such as noncontiguous selection ranges (wrong term, I guess-). We've been looking at Text performance. > I am not quite sure if Motif developers watch this newsgroup. Be assured: several of them do. When you're being drenched by a tidal wave, the first priority is continuing to breathe; indulging in conversation, while an attractive idea, has a lower priority :-) :-) > I believe that the only think CONSIDERED by OSF are BUGREPORTS. Any > suggestions here or on the motif-talk list are just whining. Only if they *are* whining :-) Like Libby said, we're all ears. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks That last signature was getting a little tired...
whitty@hpcvlx.cv.hp.com (Joe Whitty) (10/16/90)
>In article <9873@bunny.GTE.COM> dcr0@bunny.GTE.COM (David Robbins) writes: >>I have been given a small task: find a way to improve certain aspects of >>the Motif 1.0 text widget. I am relatively new to Motif, and may have >>missed some relevant discussion in this newsgroup, so bear with me. I am >> >>A) Have any of you encountered and solved performance problems with the >> text widget? If so, please share what you can with me and the net. I have done quite a bit of work to improve performance in the Motif 1.1 text widget. Unfortunately, due to some work done with the virtual key bindings and how they play with the Intrinsics, the text widget performance degraded significantly with regards to character input. Both OSF and MIT have recieved diffs to the translation manager code in the intrinsics that will fix the key event performance problem, but there is no word on when this will be added to the intrinsics. The following is a summary of what has been done to improve text widget performance: 1. In Motif 1.1, a new text field WIDGET has been added that significantly improves start-up performance of text intensive applications. 2. The text widget as well as the new text field widget share GC's among their instances. By create only two GC's for all of the text widget instances in an application, savings are realized in both the start up time and data space utilization. (Note: sharing GC's does require changing the clip rectangle prior to drawing in a different text widget) The text widget will create new text GC's when color or font attributes differ, instead of creating alot of state information and changing the GC for the different GC attributes. 3. A gapped buffer was added to the text widget to handle changes to large data buffers. The explanation for this enhancement is lengthy, but the gapped buffer essentially prevents moving large blocks of data for each character added at the beginning of a block of data. 4. Pixmaps for cursor drawing are now cached (i.e. no server round trip for cursor pixmap creation). > I had not only performance problems, but primarilly functionality > problems. Things that were supposed to work and did not, and things > that we needed but aren't there (overstrike mode, smooth scrolling > -- oh, there's a lot to be said about scrolling, source limited > to memory buffer only etc...). As we had a text widget based on Xaw > R3 widget, we'w gradually evolved it ... so today I don't see any > reason to go back and use Motif's one, based on archaic architecture > from R2 intrinsics. > I agree that Motif 1.0 definitely has performance problems, and things aren't perfect in Motif 1.1, but we are doing our best to improve performance and Motif 1.2 is targeted as a performance release. As for functionality problems, there is only so much we can do with our limited resources. We are trying to address the needs of the OSF Members while still maintaining CUA behavior requirements. The Text widget will never be everything to everyone. After all, widgets are suppose to be components in a larger application, not applications in themselves. The widgets should have better extensibility, but again, limited resources prevent us from attaining this worth while goal. >>B) Am I completely off the wall in thinking that I understand the problem? >> > Mhm. A don't think you are completely off the wall, but I am not > sure you understand the magnitude of the problem. When I took over > our text widget, I estimated 2 weeks to finish it. It took me 3+ month, > and though I dropped the code from over 10,000 lines down to 5,000 lines, > it was quite a frustrating period. No, you are not completely off the wall. I have been frustrated as well. The text widget's original implementation was done at DEC. OSF started with this implementation as it's base, and contracted HP to add the desired visuals and behavior requirements. There wasn't the time nor the resources to re-implement the text widget to have the desired performance, behavior, and extensibility. What you get with these kinds of constraints is a hack. This does NOT mean that all of Motif is a hack. Most of it is well designed and well thought out. Re-designing the text widget was and still is not among OSF's high priorities. >>C) To what extent does Motif 1.1 solve these and perhaps other performance >> problems, particularly for the text widget? (I do not have 1.1, nor do >> I expect to see it soon -- but if it answers my prayers, I may be able >> to acquire it.) > > Several people claimed significant DEGRADATION in 1.1 (I haven't received > 1.1 yet [thanks, OSF-)] ). Primarilly caused by additional functionality, > such as noncontiguous selection ranges (wrong term, I guess-). > As I explained before, it wasn't the text widget's added functionality that caused the performance degradation, it was how the translation manager in the intrisics was handling virtual bindings that caused the performance problems. 80% of the time spend on a key event was in the event getting to the text widget. Again, OSF & MIT have been provided a fix for this performance bug. >>D) Are the Motif developers aware of these problems? >> > I am not quite sure if Motif developers watch this newsgroup. From the > postings on Motif talk list, I estimate OSF has about 3 SQA people, > about 2 engineers and the God knows how many managers -). > I believe that the only think CONSIDERED by OSF are BUGREPORTS. Any > suggestions here or on the motif-talk list are just whining. Yes we are aware of these problems, and we are doing our best to improve the situation. Your suggestions do help and are appreciated. > One thing that is necessary, really necessary, is a vastly simplified > text field. I'v been told that Motif 1.1 will have a text field gadget,] > but I haven't heard about it yet. Actually, it is a text field WIDGET. I originally implemented it as a gadget, but it was depending on a proposal for changes to be made in the R4 Intrinsics that didn't get accepted by the X Consortium. Without the proposed changes, I wasn't able to put individual translations on the text field gadget. Without this capability, the only thing I could do was hard code the text bindings. The OSF members didn't go for that option so I was forced to change the gadget to a widget. There are some changes to the window structure in the R4 server that have improved the performance for widgets. This means that the performance gain for gadgets over widgets has been reduced, though gadgets still perform better. > In fact, I don't think that a gadget is a good thing here, since in absence > of a window you have to put clip rects into GC, either having a private > GC (much more expensive than a simple window), or you have to constantly > load/remove clip rects - lots of overhead again. This is exactly what I did in Motif 1.1. It was a headache, but a big performance win. The overhead wasn't unreasonable. > Such a text field would have much smaller instance, as the "big" items such > as line table and lots of the scrolling support can be nuked out. It > may share the same sink/source objects with the "big brother", as those > (if correctly implemented) may have fairly small instances. It does have a smaller instance record, less translations (multi-line translations, such as paging and scrolling, have been removed), and scrolling support has been "nuked out". At present, it doesn't share sink/source objects, and it won't until the "objects" in the text widget are truly objects and are implemented "correctly". And then there is problem of obtaining the required resources necessary to make the changes to the text field widget. I don't see this being done in the near future. > The tough task is how to inherit what's good in the "big" Text widget, so > that the Motif's typical code duplication is avoided. Again, extensibily is still a problem in Motif 1.1, so the text field doesn't share any code with the "big" Text widget. Most of the code for the text field was a total re-write. > [Few weeks ago I offered OSF to mail them the code for my text widgets > hierarchy, just to look at different optimizing techniques used, but > nothing came back. They probably know better.] Send it to me!!! I don't know any better :-). I am always open to new ideas. > -- > =*= Opinions presented here are solely of my own and not those of Auto-trol =*= > Martin Brunecky marbru@auto-trol.COM > (303) 252-2499 {...}ncar!ico!auto-trol!marbru > Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404 ---------- Joe Whitty whitty@hp-pcd.hp.com