1. Timeout instead of Scheduler
com.google.gwt.user.client.Timer seems much faster then relying on
com.google.gwt.core.client.Scheduler. I did not yet evaluate the differences in detail but the lower CPU workload speaks for itself.
I am not really sure if this helps a lot, but you will find a lot of online documentation explaining that you should use this:
com.google.gwt.animation.client.AnimationScheduler.get(). requestAnimationFrame(callback, element);. The element parameter is optional but said to improve performance as the browser can decide when to render optimally.
So whenever your timer kicks in, and you are ready to render the results, use the AnimationScheduler instead of calling your rendering routines right away. It will only take very few milliseconds (depending on the users screen frame rate—which is 60 Hz or more usually) for the callback to return to your code.
This parts requires much more effort and depends on your software architecture and requirements. The basic idea is not to redraw things that did not change. To do so we can draw each item on a hidden canvas once and then reuse this rendering during every drawing cycle.
As the process is a bit more complicated, I will dedicate it a separate post—comming soon!
4. Save on effects
Yes, effects is what the canvas is all about, but something like a shadow can cost quite some CPU power. So if you run into problems check if some of the effects can be achieved cheaper or even be removed.
When working on several large scale projects (in Eclipse), it’s convenient and of course more efficient to share and reuse code via common libraries. While those are in an early stage they need to be changed a lot and therefore it’s handy to link projects in instead of creating new jars each time the library has been updated.
Unfortunately, this standard approach for Java development in Eclipse does not work that straight forward as with plain old Java projects, it requires three steps in total:
- Link the library project to all relevant projects ("Project Preferences" -> "Java Build Path" -> "Projects" -> "Add…")
- Then, add the client-side code of the library (by adding it as a module.) Therefore, edit the gwt.xml of your application and add for example
<inherits name="net.svenbuschbeck.gwt.lib.SuperLib "/> where SuperLib is the file name of the gwt.xml file in you library project and before that is the package it lies in.
- Add the code to the project by linking a source folder. Unfortunately, this is required if you do not want to write an Ant script to compile your application. (If you prefer Ant check this out) I don’t like the idea of using such a script because if you forget to run it each time you make changes, you will end up in confusion—let’s go for the convenient, automatic way then.
- Add a folder to your application project; open the "advanced" section in the folder creation dialog, select "Link to alternate location" and pick the source folder (usually "src") of your library project. (Hint: if you work within a team using a versioning system, you can create a variable for that folder and use this instead. This way, each of your colleagues can put the library project in a different folder and accommodate for that by adjusting the variable 🙂 )
- Right click the folder, "Build Path" -> "Use as Source Folder". Done.
Surprisingly, the GWT plugin for Eclipse does not honor the project linking, thus all the references need to be made explicit or you will end up with lots of the following: ClassNotFoundException.