But it's good to record on the side the duration of one update call (can be slow generally because of physics or IA).

Just a quick question though, where do you think the best place to "pump" the profiler would be? I've got different readings when I put it in different places. For example on Sponza, I get ~300fps if I put it at the end of  MaratisPlayer::LogicLoop, if I put it at the end of the while(true) loop in main() then I get 6fps, and if I put it in draw() then I get 8fps

I'm thinking about something that could slow your machine, in MGLContext.cpp look at "sendTextureImage"
your machine probably doesn't support "glGenerateMipmapEXT" :
you'll see a commented section using "gluBuild2DMipmaps" (what I was using before),
I suggest you try removing glGenerateMipmapEXT to see if it is faster, if it is we should use gluBuild2DMipmaps if opengl < 2.0

I realise that an Intel GMA 945 netbook might not be the target machine for Maratis, but I think I would like to try and get a reasonable framerate on my netbook.

So continues my trek into profiling and optimising.

First, a couple of things I may be using in the scene that might cause the slowdown. First of all lights. The scene is pretty full with them. I can replace them with pre-generated lightmaps, but I would like for less-useless machines to still use dynamic lights where possible... so maybe having it so you can specify a lightmap, which only gets used in the fixedrenderer, and lights which only get used in the standardrenderer? Next, poly count. I will have to do some profiling where I change the amount of lights in a scene, keeping the polys the same, and then just add more polys, but I think reducing polys is always good anyway. The obvious solution to this would be to add a LoD system, and on less powerful machines (potentially exposable to players via a "detail" slider in a menu) it would use lower polygon models.

Im not sure to get the infinite update thing you said. I taught your laptop only support fixed renderer anyway ?
What fonction exactly runs slow ?

You were absolutely correct, it was a GL feature that my graphics chip didn't support. In particular it was point sprites... so yeah, the thing that I added for particles. It means I've got to be able to fallback on using billboard sprites rather than point sprites if possible. I will see if I can get it to check whether GL supports point sprites natively before enabling them...

The strange thing is, I've tried to load a more complex scene and I get an infinite update... I guess it's probably something to do with the lighting. I think it would be nice to be able to switch between a standard renderer scene and a fixed renderer scene...

I am going to see if I can steal someone's time today to take a look at it, it's probably something relatively simple I'm missing out, but I'm just not seeing it. I would really like to tune Maratis to run a bit smoother, but I can't really optimise blind like this

The 200ms missing can also be the system been late because of the slow rendering ? inputs waiting list etc.

Out of curiosity, I stuck a return in the top of draw() in main.cpp and... I got unprofiled time 1ms, 1000FPS. Moving the return down the function confirmed that it's definitely the render loop that's causing it. I'm still a bit confused why it's not showing up in the profiler at all though

At lunch, I can pastebin all of glxinfo and I can take a look at what the issue might be.
Edit: My glxinfo

If glxgear works good for you, a non-textured cube should work fine in Maratis. If not, the cause could be a particular opengl instruction, even not used but activated : Alpha-blending, alpha-testing, mip-mapping... something like that maybe.

Did you check your mesa driver ?