Subject: Re: NO consensus!
From: Paul Rohr (paul@abisource.com)
Date: Thu Apr 26 2001 - 14:07:12 CDT
At 06:13 PM 4/21/01 -0400, Leonard Rosenthol wrote:
>At 10:50 AM 4/20/2001 -0700, Paul Rohr wrote:
>>Thanks. If I understand your proposal correctly, I think we're all in
>>agreement. Indeed, I think you're proposing something nearly identical to
>>what many of us have been asking for all along.
>
> Not me!
Leonard,
Thanks for stepping up and clarifying how and where we don't have consensus
yet. I want to make sure that we have a solution that everyone understands
and can accept and that nobody hates.
>I think we can do a LOT better in terms of where the
>XP/AP lines cross. I believe that the ONLY thing that should happen in AP
>code is rendering an RGBA bitmap into platform space. All image format
>loading, manipulation (scaling, etc.) should be done in XP code!! I don't
>care whose code it is (IM, gdk-pixbuf, etc.) but I can't think of ANY GOOD
>REASON to duplicate all that stuff for each platform. We already have too
>much duplicated code, let's not add more!
Agreed. We should absolutely be doing as much as possible in XP code here.
As mentioned in the RGBA thread, if we can do enough ifdef tricks to use the
same code to get an in-memory buffer that we can hand off to each platform's
StretchBlt call, I'll be very happy.
Before we go down that path, I just want to make sure that *all* our
platforms wind up with a buffer they can cope with. I'd hate to wind up
with a code path that forced one of our platforms to do an extra in-memory
transform to rearrange the buffer generated in XP land.
>>One more summary, just to make sure we're all on the same wavelength.
>>
>>1. Images get persisted to the file format in a minimum number of file
>>formats -- PNG (and perhaps JPEG, but we don't yet have consensus on this)
>>for raster images, and SVG for vector images.
>
> That I agree with.
Thanks.
>>2. We leverage available OS libraries to import other raster and vector
>>formats. The OS specific details for this are hidden behind a flyweight XP
>>interface that can be used anyplace in AbiWord that we might run across
>>image content. [A]
>
> I can live with this IF the images are then loaded into an XP
>buffer for later processing, so that the ONLY service we are using is image
>import.
Understood. The key issue for me is whether this XP buffer is possible.
The default proposal I had on the table was to do two kinds of fanout:
- XP fanout to convert other formats to PNG/SVG on import
- platform fanout to rasterize PNG to whatever the platform prefers
The remaining code -- to persist PNG/SVG to the file format, and to parse
SVG to generate GR_Graphics draw lists -- would all be XP, with no fanout
required (beyond the extended set of GR_Graphics primitives).
In particular, if carrying around PNGs in memory is unnecessary or
undesirable *and* the RGBA buffers really are all that XP, then we may be
able to instead have less significant fanout as follows:
- XP fanout to convert other formats to RGBA on import
- mimimal platform fanout (one simple call?) to rasterize that RGBA
The remaining code would all be XP as well.
One more alternative for the sake of completeness -- I think I've been
hearing Dom propose that platforms with native support be allowed to stay
totally in platform code through the whole code path (from input file/buffer
to screen). Here there's not really fanout so much as parallelism.
>>3. For platforms which don't have a system service for image conversion, we
>>add optional XP libraries, such as libjpeg or IM or miniIM or an XP
>>gdk-pixbuf or whatever. These use the same interface(s) as needed in #2.
>
> OK.
>
>
>>4. For platforms with "weak" system services, it might be nice to to
>>augment #2 with #3. (For example, I doubt that most platforms or imaging
>>libraries have vector support that's anywhere near as useful as their raster
>>support.) If it's easy to spec the interface to do so now, great. If not,
>>we can come up with the necessary fixes as needed.
>
> You lost me on this one...Care to explain?!?!
I'll try again.
Say that your platform which has support for 7 raster formats, and you want
to use the system service for that (#2).
Say that we also have an XP implementation in the tree (#3) which supports
most of those seven, plus a dozen additional interesting raster and vector
formats.
All I'm saying is that in this case, it would be nice if our APIs and/or
build system allowed you, as platform maintainer, to mix and match (#4) the
two implementations to get a sufficiently broad superset of file format
support with the minimum amount of code.
However, if it's easier to spec an XP API which forces you to choose either
#2 or #3 exclusively, then so be it. I can live with that.
>>5. We seriously consider Hub's suggestion to streamline the import /
>>conversion process of raster images to be RGBA-centric instead of
>>PNG-centric.
>
> This is also what I am suggesting above!
That's what I thought.
>>A potential advantage of the current approach is that we can minimize the
>>in-memory footprint by carrying around compressed PNGs for images that
>>aren't on-screen.
>
> True, but we'd also slow down rendering since it would have to
>decompress each time it needs to update - and I think this is one case
>where we can spare the memory in favor of performance (IMHO).
Oh, I can't imagine doing this without some intelligent caching. The
tradeoffs are pretty blatant at the endpoints:
- You certainly don't want to decompress for every update.
- You also don't want to keep a huge uncompressed unscaled JPEG in memory
when it's offscreen and 200 pages away.
The obvious compromise would be to do JIT decompression into a cache, and
then age those images out of the cache when they go offscreen and as memory
gets tighter.
BTW, I think that we currently keep both the PNG *and* the platform-specific
RGBA equivalent in memory, so this "stupid caching" technique gets us the
best and worst of both worlds. ;-)
>>Beyond the time vs. space tradeoffs mentioned above, I think that the net
>>effect of this would be to speed up import of non-PNG content (from other
>>file formats) at the potential cost of slowing down export of our file
>>format (to re-encode the PNGs).
>
> PNG writing is pretty fast and it's at a time where the user
>doesn't mind a bit more time - as opposed to scrolling the document...
I think I see how you're balancing the tradeoffs, and would probably agree,
provided that:
- we do indeed have a usably-XP RGBA buffer, and
- the PNG --> RGBA + metadata --> PNG transform is lossless.
>>6. #5 is all about the tradeoff of various in-memory representations of
>>raster images. I suppose there'd be a corresponding tradeoff for vector
>>images. Something like SVG vs. an editable draw list of GR_Graphics
>>primitives. But hey, let's cross that bridge when we come to it. It's
>>certainly not a 1.0 issue, for instance.
>
> So you're suggesting we don't even bother with SVG till
>post-1.0? Why? Hub, Dom and I have already shown that with ImageMagick we
>can have it today (tomorrow?).
I don't know what it'll take to have WYSIWYG SVG support, and assumed that
it was a hard problem. I also must have seriously misread some of your
posts about the limitations of IM's SVG support.
I admit that I've been envisioning good SVG support as a necessary XAP core
competence for us. Over the long haul, I do assume that various AbiSuite
products will need sophisticated enough GR_Graphics implementations to
handle a bunch of SVG-like drawing primitives, such as:
- pie and bar charts in AbiCalc
- clip art and transitions in AbiShow
- etc.
Insofar as IM can replace that long-term need, I get more and more
interested.
>>7. All other embedded content (ie, not images) has an associated PNG or SVG
>>preview that can be displayed on platforms which can't edit and render the
>>associated content. [B]
>
> Agreed.
Cool. We still have some stuff to sort out, but it sounds like we're still
likely to converge on something that makes sense all around.
Paul
This archive was generated by hypermail 2b25 : Thu Apr 26 2001 - 13:59:39 CDT