[Lazarus] Graphics changes (r15472)

[Marc Weustink]

Mattias Gaertner wrote:
> On Sat, 21 Jun 2008 03:44:08 +0200
> Marc Weustink <marc at dommelstein.net> wrote:
> 
>> Mattias Gaertner wrote:
>>> On Fri, 20 Jun 2008 21:24:13 -0300
>>> Luiz Americo Pereira Camara <luizmed at oi.com.br> 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 ?

Marc