There’s a very old bug on Adobe’s JIRA bug tracker about flash video performance being absolutely abysmal on MacOS. One of the QA engineers at Adobe commented a while ago on that issue to explain that Adobe was currently focusing all their effort on mobile devices, and “didn’t have time” to fix the Mac version. There was an uproar, and the comment was removed. As I have the original in my mail, I thought I’d repost it here for posterity:

Poor performance on Mac OS X  
Updated: 10/06/09 10:09 PM   Created: 11/01/08 03:57 PM  
The following comment has been edited on this issue:	[ Permlink ]
Author: John Chen 
Created on: 05/26/09 12:16 PM
Edited by: John Chen 
Edited on: 10/07/09 11:35 AM
Comment: 
We are well aware of this issue and there is already several bugs logged in our internal system. As with all bugs, they will be worked on based on priority. 

Please be patient. 

Original comment: 
Hi everyone, 

We are well aware of this issue and there is already several bugs logged in our internal system. As with all bugs, they will be worked on based on priority. 

I know how you all feel; it pisses me off to see h.264 streaming video such as ones from hulu.com take up 70-80% cpu usage on a MAC (PC uses about 30%). It heats up my MAC, drains my batteries, and lags for a second once in a while when streaming in 420p quality. 

What can be more important than fixing this MAC specific performance issue you ask? If you do a search on Google or have went to the recent MAX conference, you will understand that our highest priority will be optimizing our player to be faster than ninjas for mobile phones (http://news.cnet.com/8301-1001_3-10098883-92.html) 

If you were CEO, what would you do? Spend resource to fix this bug (it's not like it doesn't work- it's just not as good as PC) to make a million people happy, or give Flash to everyone with phones (billions of people?). 

These MANY INSANE "optimizations and new technology" will fix many performance issues; and perhaps, this one included. 

With all that said, I'll continue to push this bug to be fixed. I would fix this bug myself if I could... 

Please be patient. 
Project:	Flash Player
Components:	 Rendering Performance
Affects Versions:	 Flash Player 10
Security Level:	Public (All JIRA Users)
Attachments:	 01 safari play.jpg, 02 safari pause.jpg, 03 camino play.jpg, 04 camino pause.jpg, 978-1.jpg, activity-monitor-snow-leopard-20090629-113345.jpg, d2bb8b2ebb2ba4e4233ccf0c80dcd7c58f30c726.png

On ngmoco’s We Rule

We Rule is a pretty boring FarmVille knock-off for iPhone and iPad. Actually, it’s really well made for what it is: nice graphics, music and atmosphere. But all you do is plant, harvest, order and deliver. I figured, maybe I can enjoy it anyway? One of the results from that is the image below.

It’s obvious ngmoco are rewarding people who spend as much time as possible in the game. The fastest way to get money is to plant the fastest crop, so that you’ll have to constantly stay in the game — 6 coins per minute. The casual gamer might plant beans and return once a day, but only get 0.3 coins per minute.

Seeing someone with a nice kingdom doesn’t mean that they are dedicated, however. If you give ngmoco real, actual money and buy ‘mojo’, they’ll shorten any waiting time to mere seconds. I understand that this is their entire business model, but I feel it takes away from any sense of accomplishment of doing things the non-paying way.

What really annoys me is what this game could have been. The makers of the game, Newtoy, helped make Age of Empires 2, so obviously they know how to make non-casual games too. I tcpdumped the server traffic and got a json description of my kingdom, which was highly interesting. They planned for several kinds of resources: stone, food and wood, which would have made for a much more complex and interesting gameplay. The best part, however, is how the json hints at armies; infantry, archers, cavalry. This game would have been absolutely *kickass* if you could attack other players! Or attack anything at all, for that matter. There is also hints of trading, another absent feature.

Perhaps these features are scheduled for a future release? I dearly hope so, but I really doubt it. I imagine Newtoy had great plans for a social medieval strategy and city-building game, and came to Ngmoco for financing. However, Ngmoco must have found the game much too inaccessible to all the casual FarmVille gamers out there; what’s the fun in building if it can be torn down? And however do you get ROI on a freemium game without heaps and bounds of casual gamers? And thus did Kingdoms (production name) become We Rule.

(I’m nevyn on Plus₊ btw, if you want to add me)

Geek Test

I scored ~38.856%. Sounds low, but apparently I’m a “major geek”. Phew!

Filtering a UITableView, and keyboard wonkiness

Hey, another bug that took half a day to fix. That always deserves a blog entry.

So I have a UITableView, and on it I have a tableHeaderView containing a UISearchBar. The UISearchBar filters the contents of the UITableView, and thus at every key press I have to reloadData (or more specifically, I -[UITableView reloadSections:withRowAnimation:]). For some reason, this calls setUserInteractionEnabled:NO on the UITableView, which in turn makes the UISearchBar’s UIFieldEditor resignFirstResponder, which makes the keyboard collapse. After the reload, user interaction is restored, UISearchBar gets focus, and the keyboard comes up.

This is rather embarrassing: I even subclassed UITableView, disabling setUserInteractionEnabled, before I realized that right there, before my eyes, is a UISearchBar delegate method called -[UISearchBarDelegate searchBarShouldEndEditing:]. Just add a bool ivar to the view controller saying whether the search bar may be resign key, set it to false before refreshing, refresh, and set it to true, and in the above delegate, return the ivar bool. Done, no more disappearing and reappearing keyboards.

Oh, and the code:

- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText {
	_searchBarMayResign = NO;
	[self.tableView reloadData]; // or equivalent
	_searchBarMayResign = YES;
}
- (BOOL)searchBarShouldEndEditing:(UISearchBar *)searchBar;
{
	return _searchBarMayResign;
}

“Exercise 4-12. Adapt the ideas of Cthulhu() to write a recursive version of the Forbidden Song of Hali; that is, to unravel the fibres of reality and allow the icy liquid darkness of Carcosa to devour your mind.”

— The C Programming Language: 4.10