Page: 0 ... 5 ... 10 ... 15 20 21 22 23 25 26 27 28 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85
|I've moved all new Win32 Lgi application builds to output minidumps when they crash (if Dbghelp.dll is present) instead of trying to create there own stack trace. I just found that it's too unreliable.
Recent Visual C++ builds do a fair job of loading the minidumps and telling you about the conditions of the crash, and I have the free version of 2008 installed on my machine. Surprisingly it even works with apps built with Visual C++ 6, which is still my primary compiler on windows (Speed baby... all speed!).
I will experiment with optionally reporting the crash dumps back to myself when the application re-starts. Hopefully this will reduce the amount of time it takes to get crashes fixed.
|(0) Comments | Add Comment
|I Need A New Phone...
|I'll be working on this sheet over the next week or so... and you can see how things progress.
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
|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
|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
|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
|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