On Tue, 25 Apr 2000, Alexander Larsson wrote:
> 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?
I agree that we need some form of renderer specific caching for certain
renderers. If we are going to use the DiaShape idea, maybe we should also
add some method of storing DiaShapes with the renderer (probably keyed by
the canvas item's address and some string).
>
> 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.
I think this was a bit of a misunderstanding on my part. The canvas items
should only ever have to worry about canvas units. The conversion to
paper or screen units is really an implementation dependent concern.
> * Set the current position of the viewport and viewport size for
> pixel-based renderers.
>
> Should i implement these as signals in the renderer?
>
> / Alex
>
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/