A few years ago I found a great site Breaking the Gigapixel Barrier about creating Giga-Pixel photos by stitching 100s of normal SLR photos together. Some people have pushed this even further with a 13 Gigapixel photo of Harlem with over 2000 photos. So my Christmas present from my wife was a new tripod and indexing head so I can take photos every 5 degrees. As my wife and I went to Las Vegas and the Grand Canyon over the holidays it was a great opportunity to try to take my first Gigapixel photo. My wife has written a blog with entertaining tales of our travels fionapotts.com. Well I did not break the Giga-Pixel barrier I managed to get to 733Mpix.

Grand Canyon 733Mpix

Its 127 12Mpix images stitched together in 3 rows every 5 degrees using a 300mm zoom lens. After some research and experimenting with different software for joining all the photos the best I found was Autopano Pro which rocks at auto detecting matching points in each photo and stitching and blending all the photos together. You can check out my results and other photos from our trip on my updated Photos Page. I took about 10 panoramas of the Grand Canyon including some HDR (High Dynamic Range) ones with 3 bracketed exposures per photo. Autopano Pro has support for stitching HDR panos but I did not have much luck as the was clear banding from photo to photo. If any of you have any tips on how to stitch HDR panos I would love to here. Well its been a fun break, back to fixing the last pre-beta Nimbus bugs tomorrow.

Hoover Dam

In the original design for Nimbus there were large,small and mini versions of components. Small and mini components are very useful when you are creating tool pallets or other UI where space is very tight. Apple recently added this to their new look and feel in the latest java versions see Technical Note TN2196. We are using the same client property key and values as Apple to be compatible but I have also added “large” as a option. Not sure “large” is as useful as “small” or “mini” but might look good in wizards or dialogs. Check out the screenshot to see how they look. 

Swing lists and tables use an implementation of ListSelectionModel to handle keeping track of the selection. Every time you change the selection or rows then the component sends those changes to the selection model to keep it in sync. The default implementation that you get is DefaultListSelectionModel. Its implmentation is highly optimized for certain kinds of operations but has had to make comprimizes for a some other operations.

Back when I was doing Imagery I created an alternative implementation of ListSelectionModel because I needed an easy way to convert the selection into a SQL where clause. After much thought I came up with the idea of representing the selection as a list of ranges of selected ids. This means that you can then convert the selection into a list of "id >= rangeMin AND id <= rangeMax" SQL expressions. This solution is well suited to the case where the selection is created by the user. The only way for a user to create more than one range is to “Control” click the rows. It is unlikely that the user will ever select more than a couple dozen ranges. This results in a model that is always simple however many rows there are in the List/Table. As a by product of this alternative selection model can be up to 88,000x faster than the default with large amounts of rows. I have put together a couple of JUnit tests, one does a huge amount of random operations on both a DefaultListSelectionModel and a RangeListSelectionModel and compares the results at each stage. This means that I can be very sure that my implementation is fully compatible with the default one. The second unit test does some performance tests to compare the two models. The data set is 1,000,000 rows and 20,000 operations for each test

Performance Results

As you can see from the results that it is a large win on average. The test that it is slow at is AddSelectionInterval this is because it ends up with 17482 ranges. This should never happen in most real world applications, the only way I can see it happen is if you select all table rows that meet some search criteria which results in 1000s of random rows being selected. In all cases where the selection is user controlled then this will never happen.

Conclusion

I have seen bug reports coming in of hugely bad JTable performance when adding/removing rows from a huge table. After profiling I found that it was the SelectionModel causing the problems. You can see from the performance results that it can take minutes to do a large chunk of selection changes on a big table. So please try out my Ranges implementation in your application and tell me how it performs. If the responses are good I could change it to the default ListSelectionModel implementation in Java 7. To use it you just need to add the line “myTable.setSelectionModel(new RangeListSelectionModel());“.

Code Downloads

Here are the sources so you can try it out for yourself:

RangeListSelectionModel.java

RangeSelectionModelPerformanceTest.java

RangeSelectionModelTest.java

Its already that time of year again to start writing up all your great ideas for Java One Desktop talks for next year. Its only two and a half weeks till they close for submissions so hurry up. Click here for details for paper submission.

I am planning on submitting a talk on Nimbus and the new Nimbus Designer tool. Covering:

• Using Nimbus L&F in your applications
• Designing for cross-platform, how to design your application to look good on all platforms
• Customizing Nimbus
• Creating new look and feels using the designer tool based on Nimbus
• Creating your own components with Nimbus L&F themeing support
• Designing the look for your own components using the deisgner tool

Might have too much to cover in a hour, don’t want to scare you all off. Any thoughts on what topics you think are the most important/intresting in case I need to cut bits out or anything I didn’t mention here?

We are looking for someone to come join us and help develop the next generation of Java Desktop. Lots of cool fun projects looking for a passionate Swing guru.

• Experience with developing Swing applications required.
• Passion for Desktop and Rich Client Applications
• Interest in designing new API for future versions of Java
• Interested in helping write cool demos for Java One and just generally showing off our technology
• Need to be in the San Francisco Bay Area or willing to move there. Also you need to be a US citizen or be able to get a visa to work in the US.

This is an amazing opportunity to work with the team who have created and shaped Desktop Java with the chance to influence the future of Java yourself. If you are interested then you can email me via the link below. Please send screenshots or links to any Swing applications you have worked on.

Email Me