Thanks for the pointer Dave, I'll make sure to modify the widgets to only add themselves onLoad/onUnload.
FYI - ResizableWidgetCollection#setResizeCheckingEnabled(false) will disable the resize check timer and only look for WindowResizeEvents. Thanks, John LaBanca [email protected] On Thu, Mar 5, 2009 at 9:36 AM, David <[email protected]> wrote: > Hi, > > Well, I just subclassed the ScrollTable and ProgressBar for now - I remove > the widgets from the collection and add them in the onLoad and remove in > onUnload, that works nicely. We have to release multiple applications the > coming days so not much time to create a patch or even switch to a new > release of GWT-incubator. > > I don't like the idea of using a Timer or even a WindowResizeListener in > widgets... but I don't see any other way to getting some feedback when > something changes in the DOM. It's a shame actually that DOM does not have > such a native event - maybe we should propose something to w3c and hope that > it gets included in our lifetime ? > > In case of the ProgressBar widget, I actually had an implementation that > did not need to recalc the div blocks. It even supported a xor effect on the > text showing the percentage (the incubator switches style when reaching > 50%). But I threw it away when I got my hands on the incubator (less > maintenance for me). > > I also had something implemented where all widgets in my DOM hierarchy > would call a layout method when one of the other widgets resized somehow. > But that meant that I had to implement this support in every widget I had in > the DOM tree. And it was triggered every time a widget was added or removed. > In a big UI that consumed a lot of CPU cycles and in many cases no resizing > was needed. I switched to using the ResizableWidget approach and the > performance is a lot better (and the code cleaner). > > I am not in favour of removing the timer. Components that need to know > should find out automatically. In small projects you can easily manage this, > but in larger organisations many bugs will arise because developers do not > care about these fine details when developing. Also, we want to reuse > busines UI objects in other UIs and then we need to expose these resizing > problems to higher level UI components. > > Some of the components of GWT have a tendency to let the app developer > handle the complexity and in many cases that can create very dangerous > dependencies in code (spaghetti code we call it). The TabPanel is such > a component: it attaches all children widgets right away, even when not in > the visible tab. If you have a widget that depends on size calculations of > the parent component then it breaks because the size will be 0. There is a > solution ofcourse, to lazyly add the panel containing the widget - but that > is more work for a developer that just wants to reuse an existing UI > component. > > David > > On Thu, Mar 5, 2009 at 2:46 PM, Joel Webber 𐑯(ټ)𐑥 <[email protected]>wrote: > >> [cc'ing John, who IIRC wrote the resizable widgets] >> >> That does indeed sound like a bad thing. At the very least, it would be >> important to get that list cleared out so that it's not growing without >> bound. And yes, onLoad/onUnload would be the right time to do it. >> >> I'm also curious about your usage of these widgets. Are they used in such >> a way that it would be relatively easy to hook the window's resize event and >> iterate over them to give them a chance to resize? And do you think that >> would be sufficient to capture the times when they actually *need* to >> resize? I ask because I've always been slightly uncomfortable with the idea >> of resizing based upon a timer, but there's no better way to do so in the >> general case -- because any change to the DOM, text, CSS, or what have you >> can, in theory, cause a widget to resize. But I'm wondering if providing >> somewhat more limited semantics (along the lines of "this widget needs to be >> told when its size changes, but it's up to the application to do so") would >> allow us to get rid of the timers altogether. >> >> Cheers, >> joel. >> >> On Thu, Mar 5, 2009 at 3:33 AM, stuckagain <[email protected]> wrote: >> >>> >>> GWT Incubator People, >>> >>> Since I don't know where to start a discussion on design decisions for >>> the incubator, I'll do it here. >>> >>> There is a fundamental problem in incubator that leads to memory leaks >>> and reduced performance. >>> >>> For example the ScrollTable (now in AbstractScrollTable) and >>> ProgressBar add themselfs to the ResizableWidgetCollection in the >>> constructor. >>> >>> The problem is that they are NEVER removed. >>> >>> Would'nt it be beter that these kind of components only add to the >>> ResizableWidgetCollection in the onLoad and remove automatically in >>> the onUnload ? >>> >>> We are using Progress Bars in Tables and many ScrollTables as well. >>> Every time that table is reconstructed, the memory usage increases. >>> After some time we also notice that the CPU usage goes up even when >>> the user is not doing anything. >>> >>> David >>> >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
