Blog
Page: 0 ... 5 ... 10 ... 15 18 19 20 21 22 23 24 25 26 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85
I Need A New Phone...
Date: 25/2/2009
I'll be working on this sheet over the next week or so... and you can see how things progress.



Columns:
  • 3G: Must have 2100 3g capabilities (I'm currently with Three)
  • USB Mass Storage: Must be able to act as a USB mass storage device when connected to a computer.
  • Charge over USB: Must be able to charge the battery over USB. Via an adapter if necessary (although I'd rather avoid adapters if I can). Nokia generally suck in this area.
  • 3.5mm audio jack: Should have a 3.5mm jack for headphones. Not a show stopper but I'd like the convenience.
  • MP3/AAC: I have a bunch of MP3/AAC's and I'd like to be able to use my phone as a media player. Decent media functions is a must.
  • H264: Must be able to playback iPod style video, aka 300-450kbit H264+AAC @ 320x240px video. Must handle videos over 1hr in length. I occasionally get stuck somewhere killing time and having a couple of movies on the phone is the best.
  • Camera: Must have an average 2MP camera. A bad camera will rule the phone out, must not suck completely. If it takes reasonable video as well, bonus! (Current phone's video recording is a joke of a slideshow)
  • Fast Menus: Showing/navigating menus must be near instantaneous, no excuses.
  • PC Sync: Should be able to replicate contacts and calendar events to an open format or API on a computer without using the bundled tools (which invariably suck).
  • Call Quality: Must have clear call quality with decent reception. No lemons please.
  • Battery life: Must have a standby of 4 days min (no music or serious usage). Call time not an issue.
  • Web Browser: Reasonable web browser, not WAP. Not a deal breaker but I'd like to be able to look some things up on the go.
  • Price: Looking at getting something used below $250. Unless it's an iPhone, which is probably worth whatever you pay for it. Killer combo on almost all fronts, still I'm hoping I can line up something I can live with for a lot less.
(Items that have been striked out are no longer being considered)

Update: I've won a k800i on the 'bay ($96aud+s/h) and I'll see how that goes for a month or 2. If it doesn't annoy the snot out of me that'll be it for a year or 2 otherwise I'll chuck it back on the 'bay and try something else. The 6600 slide is a bit steep at the moment though.

One of my friends has a k800i so I checked that it plays mpeg4 properly. And while it doesn't have the grunt for higher bitrates I found a reasonable compromise with mp4 (mpeg4 @ 430kbps, 320x240 + aac @ 64kbps). If the video bitrate is too high it skips, like up around 500kbps. I couldn't test seeking and longer movies because they didn't have a memory card. But I'm reasonably sure it'll be ok. If not there is always ebay.

Update: The one from ebay wasn't good, all sorts of problems. Wouldn't stay on, screen would go all white and become unresponsive and sometimes wouldn't turn on. Fun fun fun! Fortunately the seller is prepared to accept returns, so I'm back looking for another one as I've already bought a 4gb M2 card.
(3) Comments | Add Comment

Memory
Date: 10/2/2009
Today I did some work on the memory foot print of Scribe v2.x at startup with a large folder file and the results are in. This morning I started with a virtual memory foot print of:
82,596 kb
Which includes all data and a lot of overhead in the memory tracking lib. The absolute figure is not really important. So I analyzed the blocks and found a huge pile of them in the Xml parser. It's blocks are primarily from loading the lr8 file and keep the Xml DOM around in memory to build dialogs, strings and menus from. So I changed that over to a ref counted string pool, that cut down a huge number of tiny allocs to a few big ones. Saves on overhead... also I free'd some of the tags I didn't need anymore. Now the footprint stands at:
72,288 kb
A good start, but what else can be done? So I did a live memory dump of Scribe running at idle after startup. And after fixing some issues with the dumping and reporting I had the results, the largest allocator in the code was creating 24.3MB in 52,924 allocations from Store3Mail2.cpp:119. So I looked at that line:
return new MailData(this);
So I looked at the size of that object, and it's over 400 bytes. Owwww, that doesn't sound right. So I dug through the members and isolated the object blowing the size out. There was no easy way to remove the bulk of that object as it inherits from UI objects, however there is no real need to use that exact object, so I reimplemented a smaller implementation of the required interfaces and got the size of the MailData object down to 280 bytes. That brings the total memory footprint down to:
41,736 kb
Even nicer... Thats not bad eh! Half the memory usage.
Update: So today I did some more snooping around the memory footprint and found that all the mail2 folders are loading their entire contents into memory as objects. Normally I delay loading of items till they are needed, or at least thats the way it worked in v1.x, so I changed the Store3/Mail2 backend to work the same way as v1 and delay loading objects...
20,700 kb
Damn straight.
(1) Comment | Add Comment

Work Update
Date: 27/1/2009
I've been working away on the Linux XCB port and got to a point where the keyboard and dialogs now work mostly. Which is a decent milestone. There doesn't appear to be any support whatsoever for XCB to use input managers. So this year I hope to investigate that and maybe contribute something to XCB library to fill that functionality.

On the Mac front I've been working on getting native controls to play nicely with the custom Lgi controls, specifically the native scrollbars. So far I have that working but it crashes in carbon somewhere after it accesses a HIView that I just detached from the heirarchy and CFRelease'd. And I'm stuck in a hole trying to fix that. Which is very annoying.
(0) Comments | Add Comment

Mac Port
Date: 29/12/2008
This week I'm working on the Mac port of Scribe again. And I've almost got native scroll bars intergrated with the Lgi objects and running nicely. Almost. Makes a big difference to the look and feel of the app to have native scroll bars. I will be looking at some other native controls over the next few days. Buttons, checkboxes, radio controls and groups, tab control etc.

I'm beginning to wonder if the Mac method of doing scrollbars would work on windows. If it did I could change the architecture of scrolling so that the "Mac" way was native to Lgi and other platforms have to support it or hack it in. The difference between Mac and Windows is that on Mac, the scroll view is one control (i.e. control == HWND) and the content is a separate control, which is then just moved so that the right part of the control is in view. On windows the scrollbars are built into your HWND (if you want them) and so you have just one control/HWND and you draw in a smaller client rectangle, with you drawing offset (by setting the origin of the HDC) by the right amount. I'm wondering if you can plug a separate child control into a HWND with scrollbars, the same as the Mac. Then I could rejig the API to do that all the time. It might even have some efficency gains with scrolling blocks of graphics memory around instead of re-drawing everything.

At the moment I've made the Mac way work by reimplementing the GLayout class to shoehorn the Mac API into the way that Lgi is expecting things to work. This means that the GLayout control is owning 2 controls instead of one, and hides that fact from the layers above. But it works so I'll stick with that till I either run into a showstopper issue or I re-write it to be the native way of doing things in Lgi.

Hmmmm.... native Mac controls.
(0) Comments | Add Comment

Linux Ports
Date: 2/12/2008
The Linux ports of my apps have recently become very unstable on current distros. I suspect that the rules for using xlib have changed or something. But xlib was never really thread safe anyway so I've decided to stop avoiding the inevitable rewrite to XCB and just get on with it. My apps aren't about to stop being threaded.

So yes, the XCB re-write is happening right now. I expect that it will take a few months before anything really comes of it, but rest assured that something good is happening in Memecode's Linux world.

In a year or 3 there will most likely be a similar post about the eventual rewrite of the Mac ports to cocoa and Objective C++. (I'm not really looking forward to that either, I hate big re-writes).
(12) Comments | Add Comment

Temp files vs in memory.
Date: 28/11/2008
Most application programmers will eventually come to a point where they need to choose whether to store some data in memory or whether to write it to a temporary file. In these sorts of cases you generally don't know how much data you have to handle so the safe thing to do it to write it to disk. However that has it's downsides, it's slower, you have to make sure you clean up the file afterwards and it can get intercepted by all sorts of other processes like anti-virus.

I'm currently working on the code that handles email download in Scribe v2 and basically there needs to be a container that stores the email as it's streaming in over the socket. Initially I just used a standard in memory container (Lgi object GStringPipe) which is a FIFO sort of thing that puts it's data in fixed sized blocks. Which is kinda cool because it doesn't have to re-allocate a single block of memory to "grow" it when it runs out of space. It just allocates another block and writes to that. Anyway thats fine for about 99.8% of email. Then there is the edge case. The really insanely large email... 111mb? 456mb? I've seen some whoppers. You usually don't see those on the internet, but in a LAN situation it's not unreasonable to email a large file to someone. You know they are not particularly bandwidth limited. And I've always made it a point to handle that gracefully, both for sending and receiving. In the receiving case I stream into memory until I hit 4mb, then I create a temp file and write all the data in memory to disk, and continue streaming remaining data straight to disk. At the end of the email download I parse it in the worker thread. The cool thing about the MIME parser is that it accepts a generic stream class as input and I can give it a memory stream or a disk stream without the MIME parser caring where the data is stored. The graceful part of that system is that if you have a large email, it's not hanging around in memory, or worse virtual memory, making your system slow down.

I have had bugs before where I wrote an email to disk and for a moment closed the file, then a second later attempted to open it and it's gone. Deleted. This happens when some zealous anti-virus process decides that the email is infected. So I do take writing email to disk seriously, and in general I choose to keep the file handle open to avoid losing the data. I'm not particularly worried about infected email considering Scribe's fairly good at detecting executable attachments and blocking or deleting them.

The 4mb cut over limit is somewhat arbitrary. But I think it covers the normative case nicely.
(0) Comments | Add Comment