Marc Weustink wrote: > Mattias Gaertner wrote: >> On Sat, 21 Jun 2008 03:44:08 +0200 >> Marc Weustink <[EMAIL PROTECTED]> wrote: >> >>> Mattias Gaertner wrote: >>>> On Fri, 20 Jun 2008 21:24:13 -0300 >>>> Luiz Americo Pereira Camara <[EMAIL PROTECTED]> wrote: >>>> >>>>> Marc Weustink wrote: >>>>>> Luiz Americo Pereira Camara wrote: >>>>>> >>>>>>> One old issue i have with TBitmap (not introduced now but that >>>>>>> could be resolved with this refactoring) is that when a image is >>>>>>> loaded with LoadFromStream or LoadFromFile a copy of the image >>>>>>> buffer is kept in memory. This can speedup if is necessary to >>>>>>> access the image data directly but for the more common case of >>>>>>> loading a file to display is waste of memory. >>>>>>> >>>>>> This is no error, this is by design. And is only kept once and as >>>>>> long as the image isn't changed. Indeed, for cases where you know >>>>>> you never want to save it, we can add an property. >>>>>> >>>>> Since the most common case is not save it, just display, the >>>>> default should be not keep a copy of the stream. This my point. >>>> 1. Many images are only loaded, but never displayed. >>> ow ? which ones ? >> Sorry, maybe 'never displayed' was confusing. I meant 'often never >> displayed'. >> The forms not shown, but loaded hidden (e.g. via CreateForm). > > > Ah, I was ttalking/thinking about cases after a handle was created. > Indeed, until a handle (or now a rawimage) is created, the savestream is > needed. > >> And formerly the images of an imagelist were created only if used. > > I expected this one ;) > >>>> 2. SaveStream often contains information, that is not stored in the >>>> corresponding TGraphic class. For example header information or >>>> higher resolution. >>> Not anymore. Most important info is stored in a rawimage description >>> and/or the object itself. The stream is only kept to save an image in >>> its original format. >> And what about the other attributes? >> For example save an image in gimp and it shows for nearly any format some >> special properties. > > Yes and those extra properties are properties of the coresoponding > imageclass (like compressionratio for TJPegImage) > >> What happens to images loaded in higher resolution than the current >> resolution and is then saved without SaveStream? > > The r15472 implementation reads the raw image data in the same (or > better) format. This data is also used for writing. this way no image > details are lost. When a BitmapHandle is created, it always gets created > in a format supported by the device. This may thus be of lower quality. > With this approach, support for the PixelFormat property will be possible. > > Bitmap manipulations still happen through a device based canvas, so > currently you cannot "draw" a bitmap of a better quality than your > current device. (for the far future I'm thinking of a way to make the > canvasclass configurable, so that we can have a device independent canvas) > >>>> 3. The SaveStream is kept to make sure, that loading/saving creates >>>> the same stream. For example the IDE uses this a lot >>>> (TGraphics.Equals). >>> imo, except for jpeg maybe, load and save image code should reproduce >>> the same image. TGraphic.Equals might get adapted to use better >>> comarisation based on imagedata. >> Yes, of course, they should. But do they? > > IMO yes, pixel wise. > >> For example the xpm reader skips all comments and the extended >> attributes. And there are many ways to represent the same >> pixel/color. > > I don't see that as a problem. Look at a paint application, if you load > an image and then save it again, it hgets saved in the format of the > application, not the original file. > > If a streamcopy is needed, then you should take care of that, not the > graphic object. > >> And I don't see any extra properties of TPortableNetworkGraphic. Where >> are they stored? > > To be implemented ?
Oops, hit sent to fast. In case of the IDE, I have no opinion yet on what would be better. Keeping the original stream or write a "similar" one ourselves. In this case a KeepStream property might be a good thing. Marc _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
