Re: Canvas shortcomings

[Lauris Kaplinski <lauris ximian com>]

On 17 Jun 2001 17:43:00 +0100, Gustavo João Alves Marques Carneiro wrote:
> On 16 Jun 2001, Lauris Kaplinski wrote:
> > 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
> 
>   It can. For example, I think libplot has reasonable speed and quality
> (except for bad font quality -- X's fault). Even if it the speed isn't so
> great, it can be used interactively, with some adjustments.

AFAIK it is still vector-based API. To do decent widget rendering
one has IMHO to have acess to each pixel. In general you end with
2 almost separated API classes, which are only loosely tied under
some ubrella.
AGAIN - you can only create preview-like graphs, using solely
vector API. For interactive work one has to take into account
visual ergonomics, and descend to single pixel level.

>   Let me explain what concerns with GnomeCanvas programs. They try to do
> interaction of objects (dragging, resizing) the easy way (in terms of
> programming): to move a object, redraw it somewhere else, wherever the
> mouse pointer is.  It can be very slow with lots of objects or a single
> object the renders slowly.
> 
>  In the old days, when hardware was slower, programmers would use
> tricks like rubber banding or drawing only the object's bounding box when
> moving it, with lines drawn with the XOR function to be easy to restore
> them.
> 
>  So this is what GnomeCanvas needs, IMHO:
>     1- A very general, simple, and possibly expensive API for drawing
> objects and printing them with the same API;

OK. But let's set thing clear first:
Canvas does not need printing. It does only generate problems.
Take classic model-view application. Each canvas is single view.
If you want to print - which one would you use? Or if your program
has not opened screen view (canvas) - how do you print then?

We are horribly mixing canvas (display graph system) and general
graphic object layer here. That was one thing, I talked about.

We need General Graphic Object tree with consistent API, that can
render to:
- canvas
- printer
- OpenGL context
- ...
And I still think, that such system is not usable for rendering
widget-like objects.

Well, another approach - having only frontend API, not object
system - does not seem good to me. Again, to get interactivity
one has either to:
- do extensive re-rendering using the same API (in which case
  API has to be fast)
- have direct acess to display graph (but then frontend API
  is mostly useless)

>     2- A framework for doing rubber banding-like efects when moving and
> resizing objects, which is very inexpensive graphically (it is all done in
> the server side), but is a real pain to program manually.

In the framework above:

ObjectTree (model) has only vector-based API
Canvas (view) has rubberbanding, knots, cursors etc.
How would you define XOR drawing mode for printer? Or let it out -
but then you already split API, as user has to have additional
knowledge, which drawing codes are usable for which contexts.
Also you probably do not want to tie things like rubberbands to
model, as it does not have to appear in each view, but only
active one.

Best wishes,
Lauris Kaplinski