Motorola Xoom aint what she used to be

I have had the Motorola Xoom for a couple of years. One of the early Android tablets. It is dual core but boy is it showing its age. Part of this is due to my quad core Note II. Everything on my phone is really snappy. Things on the Xoom used to be snappy but now everything seems slow. Boot up time really stinks.

Button presses to get to home screen or bring up list of running apps are pitiful. I still use the tablet a lot for content reading. That works just as well as it always has although the screen is not super bright nor does it have the great colors of the Note II. I enjoy doing crossword puzzles more on the tablet as you can see more of the clues and all of the grid.

Not ready to get a new tablet just yet though. The Xoom works for its specific purposes. The direct plug-in charger quit working but the base charger I ordered from Amazon works just fine. If that goes out then the tablet will be useless.

Next time I will look in a smaller than 10" range but I don't know if 7" is big enough. Probably something in the middle. At least on the Android side of things there appears to be a nice variety to choose from. The current size / weight can make it a bit tough to hold one handed for extended periods of time. I am usually petting a cat while reading articles or using my other hand to one finger type crossword puzzle answers.

Java Graphics.translate is very slow

To get around an issue I was having with a JIDE CellSpanTable in a JideScrollPane hosted by a JXLayer I was using graphics.translate(x, y) but it was killing the speed of my code. I don't know what the issue happens to be with JXLayer when you call setViewPosition a Viewport of a table. It gets out of sync with JXLayer but only in the Y axis. X seems to be fine no matter what. I need to set the view port position to open of business when the grid first starts up and then at other times as I reload data from the server.

To get around the bug I used a hack of sending the new Y offset into my renderer so I could call translate and all would paint fine. It painted just as expected but the speed was horrendous. I am using the JXLayer so I can drag an appointment around on the scheduler. I fixed the problem by adjusting just the two rectangles I use for painting instead of doing a translate on the entire graphics canvas. Paints just as fast as it did before now.

It has always been slow on the Mac with or without the translate. In fact the translate call seemed to make no difference on the Mac as far as speed goes. On my i7 with 6g of RAM running Win7 64bit the speed was unusable with the translate in place.

Since this is all happening in drag and drop code trying to put a profiler on it was going to be near impossible. I knew it was running fast before so I commented out things I had recently added until I got my speed back. I knew I had made the rendering code more flexible so I thought maybe a loop in there was causing the issues. Luckily for me I had some old test code with the old rendering code and it was running slow too so I figured it had to be the recently add translate call.

It still feels like my solution is a hack and I would love to get rid of it. I tried all sorts of SwingUtilities.invokeLater variations along with setting view port position, getting horizontal and vertical scrollbar positions, resetting view port and then setting the scrollbar positions but it still just screwed up. I don' think this is a JIDE issue. I think it would screw up with a standard JTable and JScrollPane. Somehow JXLayer is just getting out of kilter.

As far as the scheduler goes it is working nicely. I have been making things faster, easier to use and cleaning up dialog box clutter. I have probably removed more lines than I have added and the whole thing is a lot easier to understand with data in objects instead of in maps with list of other maps. There are still new features to be added and it has not been seen over in QA yet.