At 10:10 PM 4/28/01 -0400, Leonard Rosenthol wrote:
>At 06:44 PM 4/27/2001 -0700, Paul Rohr wrote:
>>At 10:09 AM 4/26/01 -0400, Leonard Rosenthol wrote:
>> > The problem is that you also need to break down the areas of
>> >"image handling" as well to determine what is XP, what is platform,
>> >etc. Consider:
>> >
>> >* Raster file format handling (JPEG, PNG, etc.)
>> >* Vector file format handling (SVG, WMF, etc.)
>> >* Conversion of vector format to RGBA buffer (ie. a rasterizer!)
>> >* RGBA buffer tracking
>> >* Image manipulation (scaling, etc.)
>> >* Blitting buffer to platform "window"
>
> Out of all of these, you ONLY addressed 1, 4 and 6.
Quite right. At the moment I'm still focused on understanding how each of
the proposed designs address these three issues. In particular, the key
open issue here is the RGBA thread:
http://www.abisource.com/mailinglists/abiword-dev/01/April/1037.html
We get a useful reduction in the design space if we can get consensus on the
technical merits of RGBA-centric vs. PNG-centric solutions for raster
formats, which is what's currently our biggest need. Then we can start
considering performace issues, such as:
http://www.abisource.com/mailinglists/abiword-dev/01/April/0700.html
We're currently in a state where working XP code (Hub's libjpeg patches)
aren't being used, due to various objections about his design approach.
That'd be acceptable if we actually *had* consensus on what design we
preferred, but we don't.
That situation bothers me, so I'm investing significant effort to try to
clarify the various incomplete proposals on the table so we can *get* to
some consensus and move on.
>You still
>need to comment about vector handling (including rasterization) and image
>manipulation...
Yes, I haven't tried to drive consensus on vector and scaling issues. First
things first, though, OK?
As soon as people step up and help get the raster issues sorted out, then we
can start weighing the merits of stuff like librsvg vs mini-IM vs some
GR_Graphics homebrew (none of which I'm currently up to speed on).
>>I'll get the ball rolling by asserting that the only API I ever cared about
>>-- the switching mechanism to invoke this whole mess (from importers,
>>clipboard, etc.) -- should definitely be XP.
>
> That I agree on! However, I believe that we can reduce code
>duplication by moving more lower level stuff into XP - though perhaps this
>is post 1.0 work...
I suspect we'll agree on much of this, too.
There are likely to be many candidates for "lower-level" XP logic here, and
off the cuff, the only places where platform logic *might* be preferable are
to take advantage of any sophisticated rendering capabilities already
present.
However, as mentioned above, I'm by no means up to speed on those issues
yet. Should any of them be discussed before making headway on the
raster-format issues mentioned above?
Paul
