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.

Posted by jkeiser at April 25, 2003 8:55 PM
Comments

Are you thinking that these interfaces would be real (potentially freezable) XPCOM interfaces, or C++ pseudo-interfaces that would be bound to particular GRE versions?

The device-layer (win32GDI, X, bitmap, PS, whatever) would be almost impossible to XPCOMify in a performant manner. But the "shell" isn't hard, and the document (DOM) can already be created without a presentation... how hard would multiple presentations be?

Posted by: B. Smedberg at May 7, 2003 9:02 PM

In my implementation the presentation is a real XPCOM interfaces. Nothing here *has* to be xpcom-ified, as long as the abstraction is easy to use internally--but nsIDeviceContext is already xpcom-ified, and that's our device abstraction. There will probably be pseudo-interfaces as well for non-frozen stuff, but in the main I want a frozen interface, which is why I am asking now.

The device-layer is not hard to do, it's just that you need specific interfaces that let you create an nsIDeviceContext--which is the abstraction for the device. I have internal interfaces that create one of these presentations against an nsIDeviceContext for my new printing architecture.

If the shell isn't hard, I'd love to hear how to do it :) I need a scripting interface and docshell/webshell, without a window preferably. Multiple presentations are "easy," I'm already doing that. It's my impression that our current world is just not designed for the shell separation yet but a little work could make it so. If we can solve this problem we can have Mozilla print documents from the command line and do several other things that are not currently possible.

Posted by: jkeiser at May 8, 2003 2:20 AM

Well, (doc|web)shell have several functions that are currently intertwined, but separating them has some significant benefits for simplicity's sake as well as for windowless presentations like printing.

1) history management (and URL loading)
2) network loading management (this can mostly be hidden, I hope)
3) focus management (which really needs to be rewritten)
4) random attributes (flags whether to load subframes, plugins, objects, scripts, follow redirects, follow meta refreshes)

if these can be split up, most of the printing/static viewing stuff can implement these interfaces in trivial ways (no hx management, no JS, no focus, no scripting).

Posted by: Ben Smedberg at May 15, 2003 1:27 PM