In our previous episode, Michael Van Canneyt said: > > Ah, I don't considered those languages. At least not where any discussions > > about performance or efficiency apply ;_) > > The topic was the availability of generics. > In that field, all languages are viewed.
If you say so. Anyway, while I could try to create debate here (age of those languages, as confirmed by other reply, finding references about generics and generic-equivalent constructs in them), I'm not even interested enough in those languages to bother. At least not in FPC related language design context. > > .. or is your database layer entirely strong typed? If so, you might want to > > talk to Frank H. of GPC, he is afaik also strongly in favour of such > > approach. (and that is not meant in disrespectful way, though it is a bit a > > specialty IMHO) > > I don't know what you mean by 'strongly typed database layer', but the > contents and type of each field is known. Elementary RDBMS and some level > 3 normalization. No 'no sql' for me. Right. Should have said statically strong typed. Not related to RDBMS, but the lack of a generic db layer that requires runtime typing. Usually achieved by generating a lot of source with a preprocessor. Because that was my point. Runtime typing (variants, array of const, idispatch) are IMHO more dangerous and against pascal principles than generics, which are still statically and strong typed. >From what I see I do realize generics generally do have a rather difficult implementation. But we didn't hold back to the massive changes of the base Delphi dialect either, so that in itself is IMHO not enough reason to njet it. > >> Exactly, which is why the discussion was leading nowhere :-) > > > > There never was a discussion. Apparently the result was preset. > > You asked about my motivations, I gave them. I haven't seen anything that has relevance in FPC context. > In each case, I think I have an approach which should speed things up, and > still sticks to the design principles of fpImage. The only design I see in fpimage is a general effort to try to support anything at once. Nevermind the costs. And actually, back in the days, that was not a bad thing to have. > I checked your code, and it throws overboard much if not all that fpImage > was designed for. I'm aware that I'll probably never match what you had > in speed terms, but then you made some very limiting design choices which > I simply don't want in fpImage. The price of more generality is some > speed loss, it is always so. I don't see the need for that. I just want to keep a handful of generic storage types very fast and seperately usable, just like we essentially have one storage type (64-bit RGBA) now. This for image manipulation. Then expand the readers/writers to optionally operate rowbased, and have a few codepath simplifications in them (e.g. try to avoid the copying of rowdata to local arrays to facilitate compression and filtering in e.g. PNG if you don't use either), so that they essentially get zero-copy possibilities. I'm thinking about png, bmp and maybe jpg here. This also has consequences for reader errorhandling, it should be possible to pass a 16-bit (e.g. RGB555) memory image to a reader, and have the reader throw an exception or terminate with errorcode if the pic to load requires something bigger. (or we need a "peek" approach, to first open the image and determine the format, then allocate to custom load the memory image, and only then load it). Another annoying one that should be tackled whatever choice is made, is at least being able to override the compression level in the pngwriter. It is now always clmax which is IIRC the slowest way. (and for "photo" data, the gains are very small and not worth that). All the rarer ones keep working on the 64-bit RGBA16 base type as it is now, pixel oriented etc. I planned to see if something could be done for them after the main restructuring. A problem that I haven't thought up a solution for is autodetection of the format to safe. There have been mantis bugs about this (iirc one by Felipe), namely if you write an image you need to set options, and if you used canvas that might not be the same options as received from the image when read (e.g. a 257th color has been used, making palette impossible) But all this is guesswork, since you don't detail the problems with my approach except that you won't use generics at work, and you haven't detailed your own more than that you plan to accelerate it (but not too much) and use delegation. And of course stick to a design philisophy that is detailed nowhere. I put that crude intentionally. Since we are not going to concur at this point, it seems you'll go ahead, but I hope that it provides an incentive to be more open with it, and have some public resources. (there is a page for fcl-image in the wiki) > I would appreciate getting the really slow images if possible. > > If there are still bugs in bottom-up images, I'd like to hear about them > too, but they are an issue separate of the loading times issue; Probably a > reader problem. As far as I know, bottom-up reading is supported for BMP. It's a while ago (early last summer), and a bit in fall when XE came out. But soon I'll be picking this up again. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
