ok.

The LCL will support device/platform dependent graphics.

Do you mean gtk/gtk2/qt/win32/... specific?

I think, speed is very important and so we need the possibility to load graphics with less mappings/conversions as possible. For instance an image should not be loaded with calls to SetPixel.

Of course not.

And I guess, we can't simply emulate the VCL and their win32 bitmaps.

I think it would make sense to have a TDIB (device independent bitmap) that stores images as RGB(+Alpha) arrays with 24bit depth and a DPI setting to start with.

This could later be extented to support 1bit, 8bit and other depths. Palette formats are not so important these days.

The TDIB would go in the FCL as well as low level image file format implentations like BMP, XPM, PNG, JPG, TIFF, GIF, ... whatever.

It would be nice to be able to plug-in image format implementations so that for example one could have PNG via libpng or via native Pascal implementation.

They should descent from a common abstract image class like TGraphic. This would require TGraphic to be moved to the FCL.

All image format implementations must be able to assign from/to the TDIB format performing conversion if necessary.

Maybe for the LCL TDIB could be integrated with TBitmapImage in order to be able to share DIB's amoung several components?

Device dependent bitmaps are only useful to save memory and provide for fast GUI redrawing on non-true-color-displays, aren't they?

-Stefan

____________________________________________________________________________ Jetzt bei WEB.DE FreeMail anmelden = 1qm Regenwald schuetzen! Helfen Sie mit! Nutzen Sie den Serien-Testsieger. http://user.web.de/Regenwald

When will it be available? Does it provide a TGraphic descendant for the LCL?

-Stefan

I have sent all code to Mattias Gaertner, and I am waiting for his comments on how we should continue. At the moment, he is best placed to answer your question.

Michael.

Matthias wrote:

Who?

Yes.
The TBitmap.Handle with the gtk interface will be a pgdkimage, while with the win32 interface is a HBITMAP.

- Device dependent images are the only ones that can be used on screen. The DI images are "only" a goody to do in memory graphic manipulations.
- Using the device dependent drawing functions make use of the hardware accelerations. DI can not use them.
- DI are important for file formats and applications wthout a GUI (e.g. cgi).

So, we need both. The DD images are more important for the LCL, while the DI images are more important for the FCL.

Some notes:

Michael VC committed today the start of fpimage, the base units for device independent images. They are in an early state, but they can already load/save simple xpm/png files. Checkout the new fcl and have a look. You will find many of your ideas already implemented.
I'm currently improving the LCL to create the connection.

Mattias

I've started porting the native Delphi PNG sources available at http://pngdelphi.sourceforge.net/pngimage143.zip.
The unit compiles with FPC after applying the diff from the attachment. (The source is freeware, but I cannot distribute the modified source without permisson from the author.)

It is possible to load and save PNG Images, but the drawing functions do not work. This is due to the lack of support for DIB-related Windows API functions in the LCL. Those functions are not yet implemented. I've tried a little to find a simple way to assign the png to a bitmap but failed.

Finally I've used a simple loop to draw the picture inside TPaintBox.Paint:

    for y := 0 to png.Height - 1 do
      for x := 0 to png.Width - 1 do
        aCanvas.Pixels[x,y] := png.Pixels[x,y];

While trying to draw to an offscreen TBitmap, I found that setting Pixels does not work if there's no Widget associated with the Bitmap

Since I don't have the time to work on this in the next days, I decided to post the source ... maybe one of you wants to give it a try?

My test source is included with this mail.

Probably it would be better to get the LCL DIB stuff working instead of trying to work around it ... what do you think?

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gz00025.gz
Type: application/octet-stream
Size: 18042 bytes
Desc: "pngimage.tar.gz"
Url : http://localhost/pipermail/lazarus/attachments/20030628/7b857002/gz00025.obj

We're working on a solution in the FCL itself. It includes a PNG and XPM reader/writer, with support for all PNG features.

Michael.

I'm currently reading and testing a few things to form an opinion.

In general:
The FCL will support device/platform independent graphics. The LCL will support device/platform dependent graphics. I think, speed is very important and so we need the possibility to load graphics with less mappings/conversions as possible. For instance an image should not be loaded with calls to SetPixel. And I guess, we can't simply emulate the VCL and their win32 bitmaps.

Mattias

Hehe :-)

Check out the latest FCL. Use -dP and see the image directory. That is the basis we'll be working with. It's up for improvements, but the basics are laid out.

Michael.