Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hp-pcd!hpcvlx!whitty From: whitty@hpcvlx.cv.hp.com (Joe Whitty) Newsgroups: comp.windows.x.motif Subject: Re: Motif Text Widget Performance Problems Message-ID: <110630013@hpcvlx.cv.hp.com> Date: 15 Oct 90 20:53:15 GMT References: <9873@bunny.GTE.COM> Organization: Hewlett-Packard Co., Corvallis, OR, USA Lines: 175 >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