[lazarus] TImage

[Jens Arm]

Hi

What are you doing with your compressed archives? Now I get this errors:


linuxcvs:/Progs/te # unzip ../timage.zip
Archive:  ../timage.zip
   creating: timage/
file #2:  bad zipfile offset (local header sig):  58
file #3:  bad zipfile offset (local header sig):  6051
file #4:  bad zipfile offset (local header sig):  9030
file #5:  bad zipfile offset (local header sig):  49926
file #6:  bad zipfile offset (local header sig):  50824
file #7:  bad zipfile offset (local header sig):  52687
file #8:  bad zipfile offset (local header sig):  53366                   
                                                                    



cu Jens




>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

Am 3/12/01, 9:09:43 AM, schrieb FoodTechnologist 
<Vasily.Volchenko at mstu.edu.ru> zum Thema Re: [lazarus] TImage:


> > I think, documentation can be found. Or we can simply use the
> > gdk_pixmap_create_from_data
> > function.

> I don't think that it is needed. *.xpm structure is quite simple, but...
> It is not efficient for 16-24bpp.
> I tried to make the translation procedures (from bmp to xpm). But as for 
4 bpp,

> the translation sometimes spoil colors and now make image upside down.
> 8bpp seems to be simple enough (but I haven't made it yet), but 16-24 bpp 
seems
> to be
> too difficult. I tried to list all 256^3 colors (I don't know what is the
> reason
> to have a pallete at all), but it is not suitable. So, we must find all 
colors
> in image,
> make temporary array of color and pseudoname of it (so much memory) and 
then
> write xpm.
>  http://www.ussr.to/All/fd2lcl/timage.zip contain that what I've made. It 
uses
> my old code (as your code is not testable). It is usable for this lcl. 
Now
> 16bpp support is added.
> Besides, I've found a bug in your code: ReadSize for Bits is compared 
with
> InfoSize -
> the size of Info (line 214 of bitmap.inc of 07.03.01). It must be 
compared with
> ImgSize.

> >
> > TPicture needs conversion routines anyway.
> > Lazarus projects should be compilable anywhere. Form data is streamed to
> > the lfm file and should be readable on any system. To get graphic
> > acceleration we must use the interface dependent format. So, I think, we
> > have to read whatever format is contained in the stream and convert it to
> > an image handle.
> > AFAIK bitmap and xpm are fully convertable formats, hence we don't need 
to
> > store the data in the lcl. Of course there are other formats which loose
> > information during conversion, thus these formats must be saved in 
memory.
> >
> > > The problem is (status on 7.03.01) that TPicture isn't usefull. Besides,
> > > somebody added
> > > fmFileDenyWrite in graphic.inc
> >
> > Just comment this out.

> Course, I done it before send email. But it can frighten somebody.

> >
> > > Where is TImage component? It must be in extctrls.
> >
> > I'm very busy with the IDE and I think TBitmap/TPixmap should be 
"finished"
> > before TImage, so I did not add it.

> By the way, bitmap and pixmap are not compartible if there are 16-24bpp.
> bitmap in that case contain no pallete. Pixmap do.

> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus