Hi :) On 10/09/10 19:28, Luka Čehovin wrote:
I think we should start working on the solution for this problem step by step. First we need a baseline/reference for storing and loading ora files that is capable of accessing all the data elements in some platform independent manner.
So a separation of storage and interpretation? Probaby a good idea, given the ambitious goals of ORA.
After that a viewer can be built for a specific platform using this library and some graphics library that actually handles rendering. Putting all this functionality in one library and expecting it to render a single raster for you would be either a lot of work and a lot of code to maintain or would require using a lot of external dependencies (in my vision the basic library should be similar to libpng in terms of external dependencies).
Well by all means have a low-level library analogous to libpng - just bear in mind that if using such a library is too burdensome for application developers it won't be used. I don't want to sound pessimistic here, because ORA's a great idea - but there are two ways it could go horribly wrong:
1. The reference library doesn't provide enough functionality, and leaves the application developer to implement various filters, blends and colourspace conversions. As you rightly point out, this is a lot of work, which in this scenario has to be duplicated in each application that suports ORA. As a result, support for ORA remains patchy, and those applications which do support it have incomplete or bug-ridden implementations. End users find that using ORA causes them problems, so avoid the format.
2. The reference library provides application developers with a way of getting a flat pixel buffer from an ORA file, but doesn't support all the blend modes and filters. In this case, many applications will rapidly gain ORA support, but end users will once again find that their images don't appear correctly, and again get the impression that the format can't be "trusted" and should be avoided.
To my mind the best solution would be to have both a high-level and low-level interface - so apps which can handle layers, blend modes, etc, would use, say, libora_lowlevel, and apps that don't care about the composition of the image but just want to display or print it can use libora_highlevel to get a flat pixel buffer. If the high-level library doesn't support all blend modes, etc, then fair enough - that can be improved over time. What is vital, however, and I cannot emphasize this enough, is that if a user attempts to open an ORA file that makes use of unsupported features, the user *must* be informed that the flat pixel buffer is only a best-effort rendition.
Wow - I'm in blowhard mode tonight - hope someone finds these thoughts useful anyway. :)
All the best -- Alastair M. Robinson _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
