Blog
Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45
Sluggish Computers
Date: 28/7/2005
It's probably just me but it seems like my computers are getting slower and slower. Or my expectations are getting higher or something. But it's getting quite annoying. I know what the problem is on my main box, a 1.4ghz athlon, apart from the aging CPU clock, it only has 512mb as RAM. Which XP sp2 barely runs on. Open a few apps and it starts swaping. I've been trying very hard to convince myself to not buy some more RAM and instead put the money towards a proper hardware upgrade, like a 4200+ and supporting mobo + ram.

Anyway that sort of frustration was in the back of my mind when one Scribe user rolled back their install from v1.87 to v1.86 and mentioned how snappy the folder load times were. Which got me thinking, what happened to slow it down so much?

So I whipped out the debugger, some trace code and profiled the load times of folders. All the time was going in reading email objects off disk. So I broke that down to disk read and parse time. The disk read was trivial, so I broke the parse down to field reading and post processing. Field reads were fine... but there was a huge amount of time lost in the post processing. So digging furthur I found some crusty old code in the mail account object that delt with storing and accessing the list of mail UID's still on the server. A quick rewrite of that and it's now all clean and modern (hmmm hashtables) and lo... behold... the folder load is "Teh Snappy(TM)" again.

*the crowd roars*

(available in test11)
(5) Comments | Add Comment

New Scribe
Date: 26/7/2005
I'm almost ready to release a new build of Scribe with some fixes for SSL conectivity, HTML rendering, plugin brittle-ness and calendar bugs.

But before I do I need to confirm some things with a beta tester. Thanks for being patient everyone.
(0) Comments | Add Comment

Ye Olde Website...
Date: 21/7/2005
Ever wonder what my site looked like in 2001?

Well it appears you can still see for yourself.

Wacky wacky colour scheme. Hehe. Wow BeOS... man those were the days.
(1) Comment | Add Comment

ITMS
Date: 20/7/2005
For a number of reasons I finally decided to have a look at iTunes and ITMS. And well so far it's been a bloody mess.

Gee lets see, download and install iTunes, fairly bog standard. Run iTunes... ok all good. Type a band name in the "search music store" box and hit enter. Nothing. Ooooooook. Click "browse". Nothing. Riiiiiiight. This is obviously not going to be as easy as I thought.

Maybe I have to sign up or something to search the store, so I click "sign in" and try and use my Apple Dev ID. No luck, that'd be just too cool if it worked. So I click "create account" and follow the prompts. At which point I discover that ITMS is slow. Like watching paint dry slow. I fire up Firefox and browse a few other pages in the background, and they are all The Snappy. Ok so the net connection isn't hosed. It's just ITMS. Alright I really only want to buy 2 songs, I can live with painfully slow. Of course I want to pay with PayPal don't I so I select that and click the "verify paypal account" thingy, jump through all the hoops to hook up the paypal account and then it jumps back to the ITMS site at apple.com. I switch back to iTunes and it's still at the "choose payment type" window with the options "go back" and "cancel". Uh huh. Riiiiiight. So somehow the paypal site is supposed to tell iTunes something to go to the next stage and it didn't connect. The little bill gates devil on my should pipes up and mentions that I'm using Firefox and things might "Just Work(TM)" if I use IE instead. So out of morbid curiosity I fire up IE, make it my default browser and start the painfully slow ITMS signup from scratch. I get up to the paypal connect stage and this time I get sent back to iTunes only to get the finger: "paypal account country doesn't match ITMS country". #$*&^%#*$^@#*O$&@)#$(&*@)#($.

Now I notice the "if your billing address is not in the united states then" option and sure enough Australia is not listed there as an option is it.

So then I notice the "Choose Store" options. Click that. Wait... wait some more. 2 minutes pass. Oh ok a list of flags. No Australia. Nice. Here we are with connectivity from one end of the earth to the other and we still care about countries. Nice.

Lets recap, ITMS doesn't support firefox, doesn't support aussies, is slower than a 300 baud modem and hogs 50mb of ram. Wow... I'm speachless, so this is what all the hype has been about.

Ok back to p2p then.

I was curious to see if they carried some interesting but somewhat obsure aussie bands and also to see what the quality of AAC is like. Neither artist I wanted to listen to was listed.

And now finally, in a class peice of irony the tooltip for the search box says "quickly find songs, artists and albums". Hahaha... ha... ha....
(0) Comments | Add Comment

Windows IPC
Date: 8/7/2005
I've been looking at various forms of windows IPC and testing them against each other for latency, and I thought I would share my results with you.

The test is basically 100,000 round trips (of 4 byte msgs) between a server and a client. I was surprised at how fast standard IPC is.

Pipes: ~1100ms
Sockets: ~540ms


Sockets seems to win round 1. I've been reading about how calls into the window native API are done, as well as the architecture behind Linux syscalls. As I have an interest in being able to call into another process similar to this for a project I'm working on. Basically windows implements calls like this by loading a function id into EAX and then "int 2e" which is handled by the kernel I think. I'm assuming that it's pretty hard to setup a interrupt handler in a user space process in windows. So far I havn't worked out how to do that. I know less about the linux syscall architecture. I'm hoping of finding a way to implement that sort of thing between 2 user space processes (a server and client) that works on at least linux and windows.

IPC being the fallback if I can't get that to work.
(1) Comment | Add Comment

OpenGL shenanigans
Date: 6/7/2005
So I'm trying to build a system that uses opengl to draw dynamic 2d images in windows. I have tried using big bitmaps in memory and then glTexImage2D to create the texture from the memory bitmap. But the texture is static then... and to change the texture you have to call glTexImage2D again. Which in my case takes forever (120ms) to read the bitmap in and update the texture.

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, x, y, 0, GL_BGRA_EXT, GL_UNSIGNED_BYTE, bits);


Really what I want to do is draw on the texture using opengl. Or some other vector graphics api... although hardware acceleration is important so I'm assuming that I can't draw on the bitmap with any other type of hardware accelerated API. I really need to get my fill rate limitation off the CPU and into the GPU. Currently I've been using cairo to paint with and it's fill rate is woeful. I don't know whether that is cairo or just the CPU yet.

Maybe I will have to forget textures and just convert all the drawing commands to the opengl calls and clip the output against to the window's area. But that would mean changing the architecture to keep a display list of primitives around to "execute" everytime the screen needs updating. That doesn't sound like fun let alone an effcient way of doing things.
(5) Comments | Add Comment