This is the sort of fantastically elegant solution, to a tricky problem, that we have come to expect from 280North and Cappuccino.
The killer feature here is that "you won’t have to change a single line of code". I love how seamless this is to implement! Oh, and that the images are sent as encoded text - pure awesome.
I believe the GWT thing requires you to specifically create a bundle subclass, and put all the image files in that bundle (as methods with or without annotations). Please correct me if I'm wrong.
Yes, that's true. I think, generally speaking, base64 encoded images will result in more bytes than the original. I guess it's probably around 10%-20%.
I think, in the case of spriting, it would be fair to say that the overhead of loading many images/http requests (and their individual headers) pretty much nullifies the effects of bloating from the encoding.
I don't see this as a problem since this is for user interface elements. Pictures and larger graphics probably wouldn't be a part of this and would be handled separately.
Typical cappuccino apps are cached all at once with far future expires. Simply changing the URL (in an automated way) is enough to break the cache for new versions.
The caching tradeoff is there for any spriting technique, it will always be a tradeoff between reducing HTTP requests and increasing caching granularity.
Someone asked a similar question in the comments and this is the reply he got:
The code is all part of Objective-J and the tools, which don't require the framework itself. You could always use those in your project without using Cappuccino.
[+] [-] milestinsley|16 years ago|reply
The killer feature here is that "you won’t have to change a single line of code". I love how seamless this is to implement! Oh, and that the images are sent as encoded text - pure awesome.
[+] [-] pohl|16 years ago|reply
[+] [-] boucher|16 years ago|reply
[+] [-] gcv|16 years ago|reply
[+] [-] milestinsley|16 years ago|reply
I think, in the case of spriting, it would be fair to say that the overhead of loading many images/http requests (and their individual headers) pretty much nullifies the effects of bloating from the encoding.
[+] [-] zefhous|16 years ago|reply
[+] [-] mcav|16 years ago|reply
[+] [-] boucher|16 years ago|reply
The caching tradeoff is there for any spriting technique, it will always be a tradeoff between reducing HTTP requests and increasing caching granularity.
[+] [-] jobenjo|16 years ago|reply
[+] [-] mnemonik|16 years ago|reply
The code is all part of Objective-J and the tools, which don't require the framework itself. You could always use those in your project without using Cappuccino.
[+] [-] delano|16 years ago|reply