Re: Canvas shortcomings

[Gustavo João Alves Marques Carneiro <ee96090 fe up pt>]

On 19 Jun 2001, Lauris Kaplinski wrote:

> 
> 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.

  In that case, if you are developing and application that does serious
rendering, programmatically constrain your canvas to using a graphic
context that does client-side rendering into an RGB buffer (or better yet,
let the user decide). Just don't blame the API for being slow.  
Implementations can be slow, not APIs (usually).

> 
> 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).

  That's a good point, unfortunately :(  
  For the type of program I want to do, it woudn't matter, though.
  But there exists a solution, albeit not as easy as I hoped.  Bezier
paths wouldn't be part of the general API.  But on the next layer,  shape
objects, we could have a Bezier object, whose contructor receives the
control points and converts the bezier path into a simple vector path and
stores it internally.  You then can draw the object as many times as you
want, without having to recalculate the path.

> 
> Best wishes,
> Lauris Kaplinski
> 
> 
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
> 

-- 
Gustavo J. A. M. Carneiro
[http://linuxdeec.fe.up.pt/~ee96090]