Hacking away at GWT
rzwitserloot posted in programming on March 19th, 2007
There’s a lot of progress going on integrating Script.aculo.us and YUI-EXT (which are both effects and widget libraries for web pages, targetted at writing vanilla javascript) into GWT - the combination java to javascript compiler and widget/effects library by Google.
One of the strengths of GWT is that, due to java’s explicit static typing (I’ve talking about this before) GWT can determine, with very fine granularity, which code is actually used, and which code isn’t.
This is nice in reference to effects/widget libraries, because not sending to the browser the code for the effects/widgets that you don’t use is a nice boon; you can in effect use such a library even for just one small effect without worrying about forcing another 50k to download for every client. The digg homepage could use some of this treatment, which clocks in at a 3MB download for the whole thing.
So, while wrapping around YUI-EXT or scriptaculous is certainly a fine effort, the real solution is to rewrite it all in GWT code.
Here’s some effects I quickly hacked together: Source + demo: tipit-gwtlib.
April 9th, 2007 at 5:14
Reinier,
While I really appreciate the work you have done in writing the “million row” table widget, here is something I want to point:
Bring up “Windows task manager” and select the Performance tab. Now scroll through the table you created. Try this: Keep the left mouse key pressed on the down arrow of the scroll bar. Atleast on my machine, I could see the “CPU Usage” shooting up to 100% constant!
Dont get me wrong, I am not playing -ve here. Actually I am trying to solve similar problem for my gwt program. Your particular solution grabbed my attention.
good work!
April 9th, 2007 at 10:29
On Safari I’m getting a load of about 50% (it’s a dualcore but the load is spread over 2 processors, so it’s not just maxing out one core and not using the other one) when hold-clicking arrows, significantly less than that if I drag-scroll (scroll-wheel for trackpads), and even more than that if I drag the scrollbar.
Which browser are you using?
I have tested on MSIE6, but given that I use emulators, the performance of it on my mac is rather suspect
I don’t know of any better solution. The solution on the site is already extremely optimized; before this I had a different version which scrolled a larger div that contained all cells instead of the current version, which doesn’t have a larger div but only individual cells which get moved around. This newer version never draws new widgets (just takes an out-of-date one and moves it), and existing widgets that simply scrolled but are still visible aren’t updated at all. The previous version had to update every visible cell on scrollage, which was much slower.
Slowing the update rate might be an option, but I have tried that already and the result did eat less CPU cycles, but movement is also grating; it just doesn’t look remotely smooth, whereas now it looks decently smooth.
August 13th, 2007 at 14:18
Just a comment that I experience the same 100% CPU when drag scrolling with F/Fox 2.0.0.6 on Windows XP SP2.
Haven’t definitely made a decision to switch to DynGrid as flex table is still ok for us, but if we do and we can find any clues on this will happily post them back.
Just instinctively - it strikes me that it’s prob a simple case the drag-scroll is firing a massive number of events i.e. it’s a large list, and drag scrolling through it is probably firing an event for every single scroll. So I’d guess it’s not so much DynGrid efficiency itself, but more a question how F/Fox and JS manages such a large volume of scroll events.
August 20th, 2007 at 9:31
Can I use your code under BSD, or apache license?
August 20th, 2007 at 18:10
I should really stuff a licence on that thing. BSD licence, anyway.