Re: Canvas shortcomings

[Lauris Kaplinski <lauris ximian com>]

Hello!

Owen and everybody! What exactly we are talking about?

1. Sreamlined API, i.e.

errval = gnome_2d_shape_draw (Shape_Def, Drawing_Context)

2. Object-based API, i.e.

Gnome2DObject *obj = gnome_2d_shape_create (Shape_Def, Parent_Object)

IMHO this makes big difference.

Lauris,
worrying, that people are not talking about the same thing

On 17 Jun 2001 14:16:53 -0400, Owen Taylor wrote:
> Lauris Kaplinski <lauris ximian com> writes:
> > 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%.