Re: Canvas shortcomings

[Martin Sevior <msevior mccubbin ph unimelb edu au>]

On Sun, 17 Jun 2001, Owen Taylor wrote:

> 
> 
> Lauris Kaplinski <lauris ximian com> writes:
> 
> > Hello!
> > 
> > Unreachable goal IMHO :(
> > I have not yet find a way to make a graphic API, that:
> > 1) has reasonable speed and quality
> > 2) can be used for both interactive and output graphics
> > 3) has single, consistent API
> > 
> > If anybody knows the solution, I would be very interested.
> 
> Well, I think you have to define the parameter space a bit for
> "reasonable speed and quality". If you want perfect glyph positioning
> at all resolutions and PDF-1.4 compositing, then you probably aren't
> going to get wonderful speed.
> 
> But shooting a little lower, I think its not that hard to come up with
> a good compromise.
> 
> I'd imagine something like:
> 
>  - Primitives are glyphs and bezier shape objects
>  - A set of standard shape objects like circle, rectangle,
>    etc, derived from the base shape object.
>  - Model is painting, not a canvas
>  - Simple compositing modes (OVER, and maybe SATURATE for
>    joining glyphs)
> 
> Could meet most needs pretty darn well. That is, something a lot like
> Java2D, but maybe a bit simpler in some areas.
> 
> This primitive set, done with libart, would already have OK
> performance for a lot of uses - and if you put XRENDER behind it, it
> will blaze.
> 
> And its good enough for 98% of all printing applications. With a
> little tweaking, you could probably make that 99.95%.
> 

I conjecture that having one GtkObject per item would not yield sufficient
speed for a WordProcessor where we're constantly reshuffling text all over
the screen. Just imagine hitting delete on a line of Justified text that
swallowed the following line. All the text following needs to be cleared
and repainted. 

However I'm certainly open to counter examples that show it could be done.

Regarding the seperation between Model-View, I think what you really want
is just an interface layer between an application specific model and a
variety of rendering methods (GDK, PS whatever). The AbiWord project uses
such a layer which allows arbitary rendering backends to be plugged into a
consistent front end.

This is how we can support multiple Display systems (WIndows, QNX,
gdk,...) and is also how we print. We just open a new view on the Model
and render into a postscript or gnomeprint backend.

I also conjecture that doing this in C based API would be a challenge.

Cheers

Martin Sevior