On Thu, 21 Apr 2011, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
There is no generic way to solve this problem, because you'd need a matrix
covering all possible storage memory formats and all possible disk storage
formats.
Probably. The point is more that mostly only the diagonal of that matrix
(dumping the existing memory format to disk) is worth accelerating.
I don't understand, that precludes any line-based storage format like BMP, XPM ?
IOW the whole point is to make exceptions for a few often used cases.
Yes.
I suspect the lazarus people would be very happy to have TColor support included...
(well, I hope they will be ;) )
The best we can do is create a memory class with some pre-defined memory
storages,
with appropriate getscanline/setscanline routines and make sure the reader
classes
can
a) detect them
b) make use of them if they find one matching the file storage format.
c) fall back on the current mechanism if no fitting format is found.
If well-chosen, this approach should cover most cases.
Something like that yes. Still duplication for the various formats though.
I don't see where the duplication comes in.
There may be duplication in your classes (I don't know, but I suspect it is
the reason you switched to generics, to save typing), but with the right
delegation classes I think there is no need for duplication...
The thing will be to parametrize the needed storage formats, and then implement
the reader support for them.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
