Re: Heated agreement? (was) Re: Canvas shortcomings

[Lauris Kaplinski <lauris ximian com>]

On 27 Jun 2001 17:29:20 +1000, Nathan Hurst wrote:
> Sorry to keep going...

;)

Unfortunately for common API proponents SVP-s are not suitable for
abstract rendering API:

1. They are grid-bound - you have to convert bpath into lines, and you
   certainly do not want to do that in resolution-independent way...
2. You cannot transform SVP-s easily

So you can use SVP-s for common or reasonably similar API for low-level
graphic operations for specific grid matrix - but IMHO it does not
interface nicely with high-level, grid-independent API - which has to 
use bpaths and transformations.
Plus SVP-s are not optimizations at all for many rendering targets
(like plain X or PostScript) - so you still have to decide, which
real target you are optimizing for...

Best wishes,
Lauris Kaplinski


> On Tue, 19 Jun 2001, Mark wrote:
> > > I would suggest that we put SVP rendering into the XRender extension.  We
> > > then can do pretty much anything that pdf 1.4 can do, but with the
> > > significant speed advantages that a presorted polyline set gives.
> > 
> > As I understand the SVP (sorted vector path) is an optimization for
> > scan-line rendering. Does it have good properties for teslation too?
> 
> The most common way to find a tessellation is to convert a polygon into a
> monotonic polygons(SVP) and generate the obvious tessellation from that.
> 
> > Also XRender is meant as an abstraction of acceleration present in
> > hardware, so maybe that should be done as an extention?
> 
> XRender provides Trapezoids, which SVPs decompose into very easily.  And
> SVP is a more efficient encoding than a string of trapezoids.
> 
> njh