At 08:04 �� 13/2/2002 +0100, you wrote: >Marcel Kilgus makes some magical things to make me read >} >} What? That 32bit per pixel is far too memory consuming for a windowing >} system that does the saving of backgrounds itself? Nothing proprietary >} in this knowledge ;-) >} >} The PE was designed for 2 bit per pixel with a small resolution and >} the concept was good for that purpose. It's however a very bad design >} if you have more bits per pixel (one single(!) 800x600 window almost >} needs 2MB in 32 bit mode!). > >It would be better if PE was able to compress the saved area on the fly, >or even better, perform no saving and require a (re-)drawing routine >from each application. But then this would be trading memory for CPU >and more problems for the applications.
Well I don't think memory is of any concern for people with hi-colour mode capabilities... I don't think there are users of QPC2 and Qx0 without at least 16 Megs of RAM... As for compression of SCR, I am currently working on a modified variable RLE model (3 bytes or 4 bytes long) with the following specs: 1 bit (RLE code / 0 for <128 repetitions and 1 for >128 repetitions.) 7 bits (repetitions) (if RLE=0) or 15 bits (repetions) (if RLE>0) 16 bits (pixel data) However it's insanely slow with Basic (Peculiar thing here... VB 6.0 compiled running Atop a 1GHz Athlon is slower compression-wise than a plain QL working with Peeks and Pokes in Memory compiled with Turbo - The QL version is at least twice as fast!!! Yep the QL always had kick-a## number crunching capabilities). Decompression is extremely fast both places which is really good. Especially if the file is loaded using FS.LOAD it's practically non-noticeable... Phoebus
