Re: Canvas shortcomings

[Lauris Kaplinski <lauris ximian com>]

Hello!

On 19 Jun 2001 09:31:46 -0400, Owen Taylor wrote:
> Lauris Kaplinski <lauris ximian com> writes:
> > 
> > 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.
> 
> I don't really understand the distinction, or what you mean
> by Shape_Def.

I mean necessary data for drawing shape - i.e. bpath, stroke params,
fill params etc.

> My ideas are simply:
>  
>  - Basic API is painting, not a canvas. There is no heirarchy
>    of objects, or idea of having the entire scene in memory.
> 
>  - But instead of a PS-like "moveto lineto" scheme, you 
>    lightweight shape objects that you can create for primitives
>    like circles and rectangles.

So:
Single painting API, that can do near-identical output to RGB(A) 
  buffers, XDrawables, PrintContexts

On top of that there could be a graph tree, implementing permanent
  graphic objects - that are drawn to various backend contexts,
  using that common API

IMHO X display models kills that, because with current hardware you
cannot keep up with expose events for any serious graphic with
acceptable responsiveness. Unless you do lots of hackery in fronend, 
that removes most of the benefit of having single API. Or implementing
serious cacheing system in backend.

Current canvas caches SVP-s for reason. You absolutely do not want
to convert bez path (ArtBpath) to renderable state (SVP) for every 
drawing call - it works for simple shapes like rects and ellipses, but 
is terribly slow for complex, self-intersecting shapes. Similar
slowdown happens with advanced painting operations, like filters
(drop shadow).

Best wishes,
Lauris Kaplinski