[Lazarus] Graphics changes (r15472)

[Marc Weustink]

Marc Weustink wrote:
> 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 ?

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