On Tue, 25 Apr 2000, James Henstridge wrote:
> On Mon, 24 Apr 2000, Alexander Larsson wrote:
>
> > I've commited the first cut at the DiaRenderer interface in the
> > dia-newcanvas module. What do you think about it?
> >
> > There are still some questions about it. The largest is which unit the
> > drawing should be specified in. For screen-based renderers pixels is
> > pretty good, but that doesn't work very well for EPS etc.
>
> Some more comments on the DiaShape part of the renderer. To draw a canvas
> item, its render method will be called with a renderer object.
>
> If there are multiple views, there will be multiple renderers. Are canvas
> items required to make sure they use the correct DiaShape when rendering?
>
> I am not sure that this is the best way to handle caching data.
It will need view-specific data in items, but i thought this would be
needed anyway.
One could specify that shapes could be reused for renderers of the same
type, although this could make the implementation of some renderers
complex (think of two libart-renderers with different zoom-factors). It
would be very hard to reuse DiaShapes between two different kind of
renderers though. Consider a dia-canvas with one libart view and one Gdk
view, the shapes created for a bezier curver for these renderers will
differ very much (one being the polyline used for Gdk and one the SVP
generated by libart from an artBpath).
Caching of SVPs is essential for performance of libart-based
renderers. GnomeCanvas supports this by embedding libart-specific code in
all items. I can't see any way to do this except the DiaShape style of
renderer. What do you suggest?
When thinking about this is seems like the renderer (some at least) needs
these additional operations:
* Set unit conversion factor ("zoom factor"), units/pixel for pixel-based
renderers and unit/mm for physical renderers.
* Set the current position of the viewport and viewport size for
pixel-based renderers.
Should i implement these as signals in the renderer?
/ Alex
