| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 20 21 22 23 24 25 26 27 28 ... 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:
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 kbWhich 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 kbA 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 kbEven 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 kbDamn 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 | |