|
May 7, 2003
Printing
The new printing architecture is working, but we have scaling problems due to nsIDeviceContext doing some wacky stuff. Most pages print fine, but a few of them just have hugeass font sizes. It also looks as though pages that go off the edge of the viewport are having some shrinkage problems (part of the page is horizontally clipped on cnn.com for example).
OpenGL Again
Progress made. Lighting is all on, and I figured out the problem that was bringing my frame rate down so drastically (not sure *why* yet though): lighting. If you set the light position before you set the camera, that's bad anyway because the position is messed up, but not only that, it must be recalculating its position for every vertex or something. Still got a few white lines (which go away when you remove specular light) but the problem is not as noticeable as it was before. This took a lot of dang debugging time and a lot of reading to figure out. On the plus side, during that reading I learned a lot about vertex and pixel shading programming, which is pretty cool shit.
New things include full camera control with flythrough and an untested smooth camera follow; a lighting model minus spotlights. Metal highlights are working. I have no idea what I'm going to do with terrain yet, but it's time to tackle that along with terrain collision detection. Then a skybox and (shudder) shadows.
I wonder if moving the light around like the sun will cause the same performance problems.
April 25, 2003
Presentation Interface
OK, so let's say hypothetically you wanted to actually split our interfaces up into three conceptual things for embedders: document, shell, presentation and device. Let's further say that our embedder could do things like "presentation = new presentation(document, device)". A presentation would represent a viewport into a laid out version of the document, ready for painting. What sort of things would our hearty embedder want to do with this presentation? I've been thinking about the interface and would like some more suggestions. Actually, I haven't just been thinking about the interface, I have implemented it for printing, so this is more than an academic enterprise.
class presentation {
attributes: viewportWidth, viewportHeight, document, documentWidth, documentHeight
resize(width,height);
scrollTo(x,y);
paint();
}
So you can resize it, scroll the presentation within it, and paint it. I am somewhat confused by the sparseness of this interface, however. Perhaps DOMNode hitTest(x,y); is in order.
What else? Think dynamic screen presentation which could change over time (the presentation observes changes to the document already and handles its own animated gifs); this interactive (once events are not targeted at frames this interface should suffice, I think); think printing, think rendering onto the side of a cube in OpenGL, think anything you want.
April 21, 2003
Temporary Fix
"Temporary fixes" sure are fun.
April 15, 2003
Multiple Presentations
We've recently been having a bit of back-and-forth about the effectiveness of multiple presentation support in Mozilla, and I've reversed my earlier, less-knowledgeable position. We should continue to support them. The cost of keeping them up is minimal and they make printing and other secondary presentations work faster (and printing is slow enough as it is without cloning the document). And I haven't seen any specific proposals (yet :) for how a single presentation will help us simplify our architecture, so there's no win yet for that. Combining content and frames, the only one I can think of, is not really a popular idea yet, and I can see it might have problems (our display: mechanism, as roc pointed out, is totally centered around that dichotomy).
On a probably related issue, I've been wondering lately what the cost/benefit is of passing PresContext to every freaking method in layout (which we do now) versus just storing them in the frames or somewhere accessible. I bet changing this to storing in the frames would be a real win--you get rid of a lot of symbols and callsite pushes. If it came down to it, you could possibly avoid storing it in the textframe and instead have textframes ask their parents. I'm told someone else was thinking along the same lines in a blog lately (dbaron?) but I can't find it.
April 13, 2003
OpenGL Day Two
The engine is coming along nicely. Now I have a framework for solid objects that should allow arbitrary meshes, rudimentary lighting (with surface normal smoothing calculations built in), and a texture mapping system (it even refcounts the texture maps ;) Right now all I have to show for it is a rotating near-equilateral-pyramid in the light with somebody's face mapped onto it; but damn it feels good.
Also my objects seem to disappear after rotating them for a while. I'm thinking something goes off to 0 and then something else goes off to infinity. Next up: fix that bug, load .3DS files, camera control, and add collision detection (this will take some real doing, I know ;). Then I basically have all the stuff I need to start playing with the engine from a high level. This is going far better than should really be expected. Hooray for OpenGL!
New Spot
Oh, as you may have noticed, I have updated my weblog and moved it to Mozillazine, many thanks to kerz. This should deal with the problems some folk have been having accessing my blog.
|
