Re: [fpc-pascal] Missini graph unit
I tried ptcgraph by a mere change of names, and it works, more or less. However, the graph unit still appears in the doc, whereas I cant't find no doc for pctgraph. Some help? -- -- Elio Fabri c/o Dip. di Fisica - Univ. di Pisa -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : RE : [fpc-pascal] support for using an activex
Hi Ludo,
I really cannot get the items to work. I simplyfied the source code to
the minimum in order to test the items stuff.
var obj, item, items : variant;
obj := CreateOleObject('WRGactiveX.Device'); // OK
items := obj.Transducers; // OK
writeln('Count: ', items.Count); // OK ,
always prints 8
item := items.item[1]; // Crash: EOleSysError : Numero di
parametri non valido.
Where the exception comment translates to "wrong number of parameters".
Instead, writing item := items[1] gives the exception
EVariantInvalidArgError : Invalid argument: Dispatch
In the activex source code I hav these interface declarations:
interface ITransducer : IDispatch
{
[propget, id(1), helpstring("property Name")] HRESULT Name([out,
retval] BSTR *pVal);
[propget, id(2), helpstring("property Status")] HRESULT
Status([out,
retval] WRG_TransdStatus *pVal);
[propget, id(4), helpstring("property Meas")] HRESULT Meas([out,
retval] double *pVal);
};
interface ITransducers : IDispatch
{
[propget, id(1), helpstring("property Count")] HRESULT
Count([out,
retval] long *pVal);
[propget, id(DISPID_VALUE), helpstring("property Item")] HRESULT
Item(long Index, [out, retval] ITransducer* *pVal);
[propget, id(DISPID_NEWENUM), helpstring("property _NewEnum"),
hidden] HRESULT _NewEnum([out, retval] LPUNKNOWN *pVal);
};
and used inside the IDevice class like:
[propget, id(21), helpstring("property Transducers")] HRESULT
Transducers([out, retval] ITransducers* *pVal);
I would be very grateful if you could help me once more.
Roberto
2011/5/25 Ludo Brands :
> Using variants you can transparently "walk" along the exposed objects. The
> variant contains the Idispatch of the object and gets the exposed methods at
> runtime. Properties are implemented as get and put methods or just get
> methods for read only properties.
>
> If you have something like
> Itransducers = interface
> ..
> property transducer[Index:integer]:Itransducer;
> end;
>
> Then you would do
> transducer := transducers.transducer[index];
>
> transducer := transducers[index]; works only if transducer is the default
> property for Itransducers. I'm not sure if fpc supports this.
>
> Ludo
>
>
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org
> [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Roberto
> Padovani
> Envoyé : mercredi 25 mai 2011 19:34
> À : FPC-Pascal users discussions
> Objet : Re: RE : RE : RE : RE : RE : [fpc-pascal] support for using an
> activex
>
>
> 2011/5/25 Ludo Brands :
>> The code in article
>> http://www.informit.com/articles/article.aspx?p=130494&seqNum=5 goes a
>> long way in doing what you want to do. Unit Eventsink does pretty much
>> of the legwork. You should remove the procedure register since that is
>> the Delphi way to get a component on the toolbar. Remove also the
>> {$IFDEF VER100} and {$ENDIF}. The unit actually includes the code for
>> InterfaceConnect!!
>
> found that! great!
>
>
>> As for the tlb conversion, in your case
>>
>> IEventIntfEvents = dispinterface
>> ['{168F5642-5751-49F5-9AA4-B8A7A5F6A5B8}']
>> end;
>>
>> should do (that is for the events part). AFAIK the procedure and
>> dispid definitions are only needed for the server. You are only
>> concerned with dispid's. No need to create prototypes for
>> OnCommChanged() etc. EventSink1Invoke would be a simple case DispID of
>> 1: // do CommChanged
>> 2: // do StatesChanged
>> ...
>> end;
>>
>>
>
> Now I am "wasting" time making the tlb pascal definitions.
> For the event part I'm fine with the dispid's
> Until now I was calling the activex method with variants, in and out, but
> now I discovered that this IDevice class has a property like: property
> Sensors: ISensors;
> which inside is a list of items like Sensor: ISensor.
>
> Can I read the sensores with a variant? Then, to see the fields inside each
> sensor, I think a I need a class to do that... The activex has all of these
> classes with the suitable dispinterfaces and uuids and so on. But if I
> define
> var device, transducers, transducer : variant;
> and create
> device := CreateOleObject('Device');
> then, can i simply write the following ?
> transducers := device.Transducers;
> transducer := transducers[index];
>
>
> It's a long path until I get this stuff working...
>
> R#
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.
RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] support for using anactivex
Use Item(i). Item(long Index, [out, retval] ITransducer* *pVal); means
method with 1 input Index and Output Itransducer^.
Ludo
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org
> [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
> de Roberto Padovani
> Envoyé : lundi 30 mai 2011 14:16
> À : FPC-Pascal users discussions
> Objet : Re: RE : RE : RE : RE : RE : RE : [fpc-pascal]
> support for using anactivex
>
>
> Hi Ludo,
>
> I really cannot get the items to work. I simplyfied the
> source code to the minimum in order to test the items stuff.
>
> var obj, item, items : variant;
>
> obj := CreateOleObject('WRGactiveX.Device'); // OK
> items := obj.Transducers; // OK
> writeln('Count: ', items.Count); // OK ,
> always prints 8
>
> item := items.item[1]; // Crash: EOleSysError : Numero di
> parametri non valido.
>
> Where the exception comment translates to "wrong number of
> parameters". Instead, writing item := items[1] gives the
> exception EVariantInvalidArgError : Invalid argument: Dispatch
>
> In the activex source code I hav these interface declarations:
>
> interface ITransducer : IDispatch
> {
> [propget, id(1), helpstring("property Name")]
> HRESULT Name([out, retval] BSTR *pVal);
> [propget, id(2), helpstring("property Status")]
> HRESULT Status([out, retval] WRG_TransdStatus *pVal);
> [propget, id(4), helpstring("property Meas")]
> HRESULT Meas([out, retval] double *pVal);
> };
>
> interface ITransducers : IDispatch
> {
> [propget, id(1), helpstring("property Count")]
> HRESULT Count([out, retval] long *pVal);
> [propget, id(DISPID_VALUE),
> helpstring("property Item")] HRESULT Item(long Index, [out,
> retval] ITransducer* *pVal);
> [propget, id(DISPID_NEWENUM),
> helpstring("property _NewEnum"), hidden] HRESULT
> _NewEnum([out, retval] LPUNKNOWN *pVal);
> };
>
> and used inside the IDevice class like:
>
> [propget, id(21), helpstring("property
> Transducers")] HRESULT Transducers([out, retval] ITransducers* *pVal);
>
>
> I would be very grateful if you could help me once more.
>
> Roberto
>
>
>
> 2011/5/25 Ludo Brands :
> > Using variants you can transparently "walk" along the
> exposed objects.
> > The variant contains the Idispatch of the object and gets
> the exposed
> > methods at runtime. Properties are implemented as get and
> put methods
> > or just get methods for read only properties.
> >
> > If you have something like
> > Itransducers = interface
> > ..
> > property transducer[Index:integer]:Itransducer;
> > end;
> >
> > Then you would do
> > transducer := transducers.transducer[index];
> >
> > transducer := transducers[index]; works only if transducer is the
> > default property for Itransducers. I'm not sure if fpc
> supports this.
> >
> > Ludo
> >
> >
> > -Message d'origine-
> > De : fpc-pascal-boun...@lists.freepascal.org
> > [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
> de Roberto
> > Padovani Envoyé : mercredi 25 mai 2011 19:34
> > À : FPC-Pascal users discussions
> > Objet : Re: RE : RE : RE : RE : RE : [fpc-pascal] support
> for using an
> > activex
> >
> >
> > 2011/5/25 Ludo Brands :
> >> The code in article
> >>
> http://www.informit.com/articles/article.aspx?p=130494&seqNum=5 goes
> >> a long way in doing what you want to do. Unit Eventsink
> does pretty
> >> much of the legwork. You should remove the procedure
> register since
> >> that is the Delphi way to get a component on the toolbar.
> Remove also
> >> the {$IFDEF VER100} and {$ENDIF}. The unit actually
> includes the code
> >> for InterfaceConnect!!
> >
> > found that! great!
> >
> >
> >> As for the tlb conversion, in your case
> >>
> >> IEventIntfEvents = dispinterface
> >> ['{168F5642-5751-49F5-9AA4-B8A7A5F6A5B8}']
> >> end;
> >>
> >> should do (that is for the events part). AFAIK the procedure and
> >> dispid definitions are only needed for the server. You are only
> >> concerned with dispid's. No need to create prototypes for
> >> OnCommChanged() etc. EventSink1Invoke would be a simple
> case DispID
> >> of
> >> 1: // do CommChanged
> >> 2: // do StatesChanged
> >> ...
> >> end;
> >>
> >>
> >
> > Now I am "wasting" time making the tlb pascal definitions. For the
> > event part I'm fine with the dispid's Until now I was calling the
> > activex method with variants, in and out, but now I discovered that
> > this IDevice class has a property like: property
> > Sensors: ISensors;
> > which inside is a list of items like Sensor: ISensor.
> >
> > Can I read the sensores with a variant? Then, to see the
> fields inside
> > each sensor, I think a I need a class to do that... The activex has
> > all of these classes with the suitable dispinterfaces and
> uuids and so
> > on. But if
[fpc-pascal] Why is FPImage dog slow in reading jpeg's?
Hi,
I wrote this console utility app in 5 minutes. All it is supposed to
do, is iterate over *.jpg images (65 at the moment) in a folder (no
recursive searches), and generate a snipped of HTML that I need to
paste into my wives website.
I first thought my utility app is in some recursive loop or something
because the output didn't appear instantly - like I thought it would.
I added some debug output between the generate HTML. To my surprise
the FPImage code reading a 35Kb jpg file takes +- 8 seconds and a 65KB
file takes +- 30 seconds - on a Quad Core machine! WTF???
Is this normal? Is FPImage really that slow reading small roughly
650x450 pixel jpg images? Or am I doing something unbelievably
stupid? :-/
The reason I'm reading in the jpg files is so I can get their Width
and Height values. Avg. jpeg file sizes are between 35-45KB, and
largest file size is 65KB.
Here is the relevant code snippet
var
imgreader: TFPReaderJPEG;
stream: TFileStream;
img:TFPCustomImage;
writeln('processing file: ', filelist[i]);
stream := TFileStream.Create(filelist[i], fmOpenRead);
writeln(1);
imgreader := TFPReaderJPEG.Create;
writeln(2, FormatDateTime(' hh:mm:ss.zz', Now) + ' (start reading)');
img := imgreader.ImageRead(stream, nil);
writeln(3, FormatDateTime(' hh:mm:ss.zz', Now) + ' (done)');
Here is the program output... Note the timestamps between start
reading and done reading (lines marked with '2' and '3').
---[ start ]---
$ ./project1 img/babies/full
Finished search. Found 65 matches
---
processing file: img/babies/full/babies.01.jpg
1
2 16:00:30.210 (start reading)
3 16:00:38.338 (done)
processing file: img/babies/full/babies.02.jpg
1
2 16:00:38.338 (start reading)
3 16:01:10.447 (done)
processing file: img/babies/full/babies.03.jpg
1
2 16:01:10.447 (start reading)
3 16:01:28.859 (done)
processing file: img/babies/full/babies.04.jpg
1
2 16:01:28.859 (start reading)
snip
---[ end ]---
--
Ben.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] why is FPImage dog slow reading jpeg's?
Hi,
I wrote this console utility app in 5 minutes. All it is supposed to do,
is iterate over *.jpg images (65 at the moment) in a folder (no
recursive searches), and generate a snipped of HTML that I need to paste
into my wives website.
I first thought my utility app is in some recursive loop or something
because the output didn't appear instantly - like I thought it would.
I added some debug output between the generate HTML. To my surprise the
FPImage code reading a 35Kb jpg file takes +- 8 seconds and a 65KB file
takes +- 30 seconds - on a Quad Core machine! WTF???
Is this normal? Is FPImage really that slow reading small roughly
650x450 pixel jpg images? Or am I doing something unbelievably stupid? :-/
The reason I'm reading in the jpg files is so I can get their Width and
Height values. Avg. jpeg file sizes are between 35-45KB, and largest
file size is 65KB.
Here is the relevant code snippet
var
imgreader: TFPReaderJPEG;
stream: TFileStream;
img:TFPCustomImage;
writeln('processing file: ', filelist[i]);
stream := TFileStream.Create(filelist[i], fmOpenRead);
writeln(1);
imgreader := TFPReaderJPEG.Create;
writeln(2, FormatDateTime(' hh:mm:ss.zz', Now) + ' (start reading)');
img := imgreader.ImageRead(stream, nil);
writeln(3, FormatDateTime(' hh:mm:ss.zz', Now) + ' (done)');
Here is the program output... Note the timestamps between start reading
and done reading (lines marked with '2' and '3').
---[ start ]---
$ ./project1 img/babies/full
Finished search. Found 65 matches
---
processing file: img/babies/full/babies.01.jpg
1
2 16:00:30.210 (start reading)
3 16:00:38.338 (done)
processing file: img/babies/full/babies.02.jpg
1
2 16:00:38.338 (start reading)
3 16:01:10.447 (done)
processing file: img/babies/full/babies.03.jpg
1
2 16:01:10.447 (start reading)
3 16:01:28.859 (done)
processing file: img/babies/full/babies.04.jpg
1
2 16:01:28.859 (start reading)
snip
---[ end ]---
--
Ben.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
Try the following code:
Img:=TFPMemoryImage.Create(0,0);
Img.UsePalette:=False;
Img.loadFromFile(FileList[i]);
That should work much faster. The reason is probably that the default image
created by the reader uses a palette, which is of course dog slow when reading
large images.
Michael.
On Mon, 30 May 2011, Ben Smith wrote:
Hi,
I wrote this console utility app in 5 minutes. All it is supposed to
do, is iterate over *.jpg images (65 at the moment) in a folder (no
recursive searches), and generate a snipped of HTML that I need to
paste into my wives website.
I first thought my utility app is in some recursive loop or something
because the output didn't appear instantly - like I thought it would.
I added some debug output between the generate HTML. To my surprise
the FPImage code reading a 35Kb jpg file takes +- 8 seconds and a 65KB
file takes +- 30 seconds - on a Quad Core machine! WTF???
Is this normal? Is FPImage really that slow reading small roughly
650x450 pixel jpg images? Or am I doing something unbelievably
stupid? :-/
The reason I'm reading in the jpg files is so I can get their Width
and Height values. Avg. jpeg file sizes are between 35-45KB, and
largest file size is 65KB.
Here is the relevant code snippet
var
imgreader: TFPReaderJPEG;
stream: TFileStream;
img:TFPCustomImage;
writeln('processing file: ', filelist[i]);
stream := TFileStream.Create(filelist[i], fmOpenRead);
writeln(1);
imgreader := TFPReaderJPEG.Create;
writeln(2, FormatDateTime(' hh:mm:ss.zz', Now) + ' (start reading)');
img := imgreader.ImageRead(stream, nil);
writeln(3, FormatDateTime(' hh:mm:ss.zz', Now) + ' (done)');
Here is the program output... Note the timestamps between start
reading and done reading (lines marked with '2' and '3').
---[ start ]---
$ ./project1 img/babies/full
Finished search. Found 65 matches
---
processing file: img/babies/full/babies.01.jpg
1
2 16:00:30.210 (start reading)
3 16:00:38.338 (done)
processing file: img/babies/full/babies.02.jpg
1
2 16:00:38.338 (start reading)
3 16:01:10.447 (done)
processing file: img/babies/full/babies.03.jpg
1
2 16:01:10.447 (start reading)
3 16:01:28.859 (done)
processing file: img/babies/full/babies.04.jpg
1
2 16:01:28.859 (start reading)
snip
---[ end ]---
--
Ben.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] support for using anactivex
With the round bracketitem := items.item(1);
it crasches saying "Cannot find member"
I am declaring only variants as you suggestedmaybe for collections
I have to declare explicitely some interfaces? I tried without
success, but not knowing COM at all, I might have written something
wrong.
I've seen around variants and olevariants...??
Could it be an error or non-standard implementation of the dll ?
I'm loosing confidence.
Thanks anyway!!
R#
2011/5/30 Ludo Brands :
> Use Item(i). Item(long Index, [out, retval] ITransducer* *pVal); means
> method with 1 input Index and Output Itransducer^.
>
> Ludo
>
>> -Message d'origine-
>> De : fpc-pascal-boun...@lists.freepascal.org
>> [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
>> de Roberto Padovani
>> Envoyé : lundi 30 mai 2011 14:16
>> À : FPC-Pascal users discussions
>> Objet : Re: RE : RE : RE : RE : RE : RE : [fpc-pascal]
>> support for using anactivex
>>
>>
>> Hi Ludo,
>>
>> I really cannot get the items to work. I simplyfied the
>> source code to the minimum in order to test the items stuff.
>>
>> var obj, item, items : variant;
>>
>> obj := CreateOleObject('WRGactiveX.Device'); // OK
>> items := obj.Transducers; // OK
>> writeln('Count: ', items.Count); // OK ,
>> always prints 8
>>
>> item := items.item[1]; // Crash: EOleSysError : Numero di
>> parametri non valido.
>>
>> Where the exception comment translates to "wrong number of
>> parameters". Instead, writing item := items[1] gives the
>> exception EVariantInvalidArgError : Invalid argument: Dispatch
>>
>> In the activex source code I hav these interface declarations:
>>
>> interface ITransducer : IDispatch
>> {
>> [propget, id(1), helpstring("property Name")]
>> HRESULT Name([out, retval] BSTR *pVal);
>> [propget, id(2), helpstring("property Status")]
>> HRESULT Status([out, retval] WRG_TransdStatus *pVal);
>> [propget, id(4), helpstring("property Meas")]
>> HRESULT Meas([out, retval] double *pVal);
>> };
>>
>> interface ITransducers : IDispatch
>> {
>> [propget, id(1), helpstring("property Count")]
>> HRESULT Count([out, retval] long *pVal);
>> [propget, id(DISPID_VALUE),
>> helpstring("property Item")] HRESULT Item(long Index, [out,
>> retval] ITransducer* *pVal);
>> [propget, id(DISPID_NEWENUM),
>> helpstring("property _NewEnum"), hidden] HRESULT
>> _NewEnum([out, retval] LPUNKNOWN *pVal);
>> };
>>
>> and used inside the IDevice class like:
>>
>> [propget, id(21), helpstring("property
>> Transducers")] HRESULT Transducers([out, retval] ITransducers* *pVal);
>>
>>
>> I would be very grateful if you could help me once more.
>>
>> Roberto
>>
>>
>>
>> 2011/5/25 Ludo Brands :
>> > Using variants you can transparently "walk" along the
>> exposed objects.
>> > The variant contains the Idispatch of the object and gets
>> the exposed
>> > methods at runtime. Properties are implemented as get and
>> put methods
>> > or just get methods for read only properties.
>> >
>> > If you have something like
>> > Itransducers = interface
>> > ..
>> > property transducer[Index:integer]:Itransducer;
>> > end;
>> >
>> > Then you would do
>> > transducer := transducers.transducer[index];
>> >
>> > transducer := transducers[index]; works only if transducer is the
>> > default property for Itransducers. I'm not sure if fpc
>> supports this.
>> >
>> > Ludo
>> >
>> >
>> > -Message d'origine-
>> > De : fpc-pascal-boun...@lists.freepascal.org
>> > [mailto:fpc-pascal-boun...@lists.freepascal.org] De la part
>> de Roberto
>> > Padovani Envoyé : mercredi 25 mai 2011 19:34
>> > À : FPC-Pascal users discussions
>> > Objet : Re: RE : RE : RE : RE : RE : [fpc-pascal] support
>> for using an
>> > activex
>> >
>> >
>> > 2011/5/25 Ludo Brands :
>> >> The code in article
>> >>
>> http://www.informit.com/articles/article.aspx?p=130494&seqNum=5 goes
>> >> a long way in doing what you want to do. Unit Eventsink
>> does pretty
>> >> much of the legwork. You should remove the procedure
>> register since
>> >> that is the Delphi way to get a component on the toolbar.
>> Remove also
>> >> the {$IFDEF VER100} and {$ENDIF}. The unit actually
>> includes the code
>> >> for InterfaceConnect!!
>> >
>> > found that! great!
>> >
>> >
>> >> As for the tlb conversion, in your case
>> >>
>> >> IEventIntfEvents = dispinterface
>> >> ['{168F5642-5751-49F5-9AA4-B8A7A5F6A5B8}']
>> >> end;
>> >>
>> >> should do (that is for the events part). AFAIK the procedure and
>> >> dispid definitions are only needed for the server. You are only
>> >> concerned with dispid's. No need to create prototypes for
>> >> OnCommChanged() etc. EventSink1Invoke would be a simple
>> case DispID
>> >> of
>> >> 1: // do CommChanged
>> >> 2: // do StatesChanged
>> >> ...
>> >> end;
>> >>
>> >>
>> >
>> > Now I am "wasting" time mak
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, May 30, 2011 at 4:16 PM, Michael wrote: > snip > That should work much faster. The reason is probably that the default image Ah, thanks Michael that did the trick. I knew I had to be doing something wrong. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, May 30, 2011 16:16, michael.vancann...@wisa.be wrote:
>
> Try the following code:
>
> Img:=TFPMemoryImage.Create(0,0);
> Img.UsePalette:=False;
> Img.loadFromFile(FileList[i]);
>
> That should work much faster. The reason is probably that the default
> image
> created by the reader uses a palette, which is of course dog slow when
> reading
> large images.
Interesting. What is supposed to be a "large image"? I ask because the
original post mentioned 35 kB and 65 kB (and indirectly also dimensions
around 600x400 if I understand the program output correctly) which I
certainly wouldn't consider as "large" (and the mentioned time necessary
for reading it surely not appropriate regardless of using palette or not).
I guess that some optimization may be reasonable because such pictures
could be loaded and displayed (including conversion from true colour to
256 colours palette) faster even on a 486 machine...
Tomas
>
> On Mon, 30 May 2011, Ben Smith wrote:
>
>> Hi,
>>
>> I wrote this console utility app in 5 minutes. All it is supposed to
>> do, is iterate over *.jpg images (65 at the moment) in a folder (no
>> recursive searches), and generate a snipped of HTML that I need to
>> paste into my wives website.
>>
>> I first thought my utility app is in some recursive loop or something
>> because the output didn't appear instantly - like I thought it would.
>>
>> I added some debug output between the generate HTML. To my surprise
>> the FPImage code reading a 35Kb jpg file takes +- 8 seconds and a 65KB
>> file takes +- 30 seconds - on a Quad Core machine! WTF???
>>
>> Is this normal? Is FPImage really that slow reading small roughly
>> 650x450 pixel jpg images? Or am I doing something unbelievably
>> stupid? :-/
>>
>> The reason I'm reading in the jpg files is so I can get their Width
>> and Height values. Avg. jpeg file sizes are between 35-45KB, and
>> largest file size is 65KB.
>>
>> Here is the relevant code snippet
>>
>> var
>> imgreader: TFPReaderJPEG;
>> stream: TFileStream;
>> img:TFPCustomImage;
>>
>>
>>
>> writeln('processing file: ', filelist[i]);
>> stream := TFileStream.Create(filelist[i], fmOpenRead);
>> writeln(1);
>> imgreader := TFPReaderJPEG.Create;
>> writeln(2, FormatDateTime(' hh:mm:ss.zz', Now) + ' (start reading)');
>> img := imgreader.ImageRead(stream, nil);
>> writeln(3, FormatDateTime(' hh:mm:ss.zz', Now) + ' (done)');
>>
>>
>>
>>
>> Here is the program output... Note the timestamps between start
>> reading and done reading (lines marked with '2' and '3').
>>
>>
>> ---[ start ]---
>> $ ./project1 img/babies/full
>> Finished search. Found 65 matches
>> ---
>>
>>
>>
>>
>> processing file: img/babies/full/babies.01.jpg
>> 1
>> 2 16:00:30.210 (start reading)
>> 3 16:00:38.338 (done)
>> > class="imglarge" onmouseout="reducethumb(1); return false;"
>> onclick="reducethumb(1); return false;">
>> > id="thumb1" onclick="expandthumb(1, 650, 413);">
>>
>>
>>
>>
>> processing file: img/babies/full/babies.02.jpg
>> 1
>> 2 16:00:38.338 (start reading)
>> 3 16:01:10.447 (done)
>> > class="imglarge" onmouseout="reducethumb(2); return false;"
>> onclick="reducethumb(2); return false;">
>> > id="thumb2" onclick="expandthumb(2, 650, 435);">
>>
>>
>>
>>
>> processing file: img/babies/full/babies.03.jpg
>> 1
>> 2 16:01:10.447 (start reading)
>> 3 16:01:28.859 (done)
>> > class="imglarge" onmouseout="reducethumb(3); return false;"
>> onclick="reducethumb(3); return false;">
>> > id="thumb3" onclick="expandthumb(3, 405, 650);">
>>
>>
>>
>>
>> processing file: img/babies/full/babies.04.jpg
>> 1
>> 2 16:01:28.859 (start reading)
>>
>> snip
>> ---[ end ]---
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, 30 May 2011, Tomas Hajny wrote: On Mon, May 30, 2011 16:16, michael.vancann...@wisa.be wrote: Try the following code: Img:=TFPMemoryImage.Create(0,0); Img.UsePalette:=False; Img.loadFromFile(FileList[i]); That should work much faster. The reason is probably that the default image created by the reader uses a palette, which is of course dog slow when reading large images. Interesting. What is supposed to be a "large image"? I ask because the original post mentioned 35 kB and 65 kB (and indirectly also dimensions around 600x400 if I understand the program output correctly) which I certainly wouldn't consider as "large" (and the mentioned time necessary for reading it surely not appropriate regardless of using palette or not). I guess that some optimization may be reasonable because such pictures could be loaded and displayed (including conversion from true colour to 256 colours palette) faster even on a 486 machine... It depends on the colors used. The default palette algorithm simply allocates a slot per found color in the jpg and returns the index of the slow. For a picture, this will create a huge palette, in which the search for a color is in essence linear, so n^2 lookups. So, dog slow. You could obviously speed this up by creating a palette yourself, and limiting the number of colors. Or, best for pictures is not to use a palette, which is what my solution entails. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
> > Interesting. What is supposed to be a "large image"? I ask because the > original post mentioned 35 kB and 65 kB (and indirectly also dimensions > around 600x400 if I understand the program output correctly) which I I suppose he was referring to the "color palette", and not the physical image size. I guess that is why The Gimp limits png images to 256 colors when I saved it as Indexed (which then generates a color palette). So I guess it is a standard issue with Index/Palette images thus limit your colors, or don't use a palette. I guess one change in FPImage (depending on how often this occurs obviously), could be to default to UsePalette = False instead. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
Tomas Hajny hat am 30. Mai 2011 um 16:50 geschrieben: > On Mon, May 30, 2011 16:16, michael.vancann...@wisa.be wrote: > > > > Try the following code: > > > > Img:=TFPMemoryImage.Create(0,0); > > Img.UsePalette:=False; > > Img.loadFromFile(FileList[i]); > > > > That should work much faster. The reason is probably that the default > > image > > created by the reader uses a palette, which is of course dog slow when > > reading > > large images. > > Interesting. What is supposed to be a "large image"? I ask because the > original post mentioned 35 kB and 65 kB (and indirectly also dimensions > around 600x400 if I understand the program output correctly) which I > certainly wouldn't consider as "large" (and the mentioned time necessary > for reading it surely not appropriate regardless of using palette or not). > I guess that some optimization may be reasonable because such pictures > could be loaded and displayed (including conversion from true colour to > 256 colours palette) faster even on a 486 machine... Is there any size, where a palette image is fast? I think this is a newbie trap and the default for UsePalette should be changed. Mattias___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, May 30, 2011 16:59, michael.vancann...@wisa.be wrote: > On Mon, 30 May 2011, Tomas Hajny wrote: >> On Mon, May 30, 2011 16:16, michael.vancann...@wisa.be wrote: >>> >>> Try the following code: >>> >>> Img:=TFPMemoryImage.Create(0,0); >>> Img.UsePalette:=False; >>> Img.loadFromFile(FileList[i]); >>> >>> That should work much faster. The reason is probably that the default >>> image >>> created by the reader uses a palette, which is of course dog slow when >>> reading >>> large images. >> >> Interesting. What is supposed to be a "large image"? I ask because the >> original post mentioned 35 kB and 65 kB (and indirectly also dimensions >> around 600x400 if I understand the program output correctly) which I >> certainly wouldn't consider as "large" (and the mentioned time necessary >> for reading it surely not appropriate regardless of using palette or >> not). >> I guess that some optimization may be reasonable because such pictures >> could be loaded and displayed (including conversion from true colour to >> 256 colours palette) faster even on a 486 machine... > > It depends on the colors used. The default palette algorithm simply > allocates a slot per found color in the jpg and returns the index of the > slow. For a picture, this will create a huge palette, in which the search > for a color is in essence linear, so n^2 lookups. > > So, dog slow. > > You could obviously speed this up by creating a palette yourself, and > limiting the number of colors. > > Or, best for pictures is not to use a palette, which is what my solution > entails. OK, I see. The point is not about what I need or not (I don't need to work with pictures at the moment) but about what will happen if people start using the current code as it is provided in FCL. I'm sure there are various possibilities for some "optimization" - should it be using a different (faster) algorithm for creating the palette (e.g. different algorithms depending on whether the original picture contains a palette or not), not creating the palette by default for pictures not using it (or not doing it at all unless explicitly requested, i.e. changing the default behaviour as suggested by Matthias), limiting the maximum colour depth for pictures with palette (as mentioned by Ben), etc. In any case, I'm afraid that the current default behaviour will not work well for majority of FPC users and their use cases. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] support for usinganactivex
> With the round bracketitem := items.item(1); > it crasches saying "Cannot find member" Difficult to debug without having the dll. If item := items.item[1]; raises a "wrong number of parameters then the items.item member is found. I don't understand why items.item(1) raises a "Cannot find member". COM methods are normally case insensitive. > I am declaring only variants as you suggestedmaybe for > collections I have to declare explicitely some interfaces? I didn't notice the id(DISPID_VALUE) in the Item declaration. This means that item:=items(i) should work also. Don't know if fpc supports this. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
michael.vancann...@wisa.be wrote: Try the following code: Img:=TFPMemoryImage.Create(0,0); Img.UsePalette:=False; Img.loadFromFile(FileList[i]); That should work much faster. The reason is probably that the default image created by the reader uses a palette, which is of course dog slow when reading large images. Pardon me for jumping in, but is there an equivalent fix for slow operations in a TLazIntfImage? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] support for usinganactivex
I created a small automation object with following IDL (part of it):
interface ItestAX: IDispatch
{
[
propget,
id(0x0001)
]
HRESULT _stdcall Devices([out, retval] IDevices ** Value );
};
interface IIDevices: IDispatch
{
[
propget,
id(0x)
]
HRESULT _stdcall Device([in] long Idx, [out, retval] IDevice ** Value );
[
propget,
id(0x0002)
]
HRESULT _stdcall Count([out, retval] long * Value );
};
interface IIDevice: IDispatch
{
[
propget,
id(0x0001)
]
HRESULT _stdcall Name([out, retval] BSTR * Value );
};
This matches pretty much the interface you described earlier. Note the
id(0x) which makes Device the default member of IIDevices. This is
the same as id(DISPID_VALUE) in your case.
Now, the following lines do work for me to get the Name member of IIDevice
(ActX,a,b:variant;s:string):
ActX:=CreateOleObject(MyTestControl);
a:=ActX.Devices;
b:=a.Device[3];
s:=b.Name;
b:=ActX.Devices.Device[3];
s:=b.Name;
b:=ActX.Devices[3];
s:=b.Name;
Note that the default member does work correctly:
Devices.Device[3]===Devices[3].
I'm using fpc 2.5.1 svn 17599.
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On 30 May 2011, at 16:59, michael.vancann...@wisa.be wrote: > It depends on the colors used. The default palette algorithm simply allocates > a slot per found color in the jpg and returns the index of the > slow. For a picture, this will create a huge palette, in which the search for > a color is in essence linear, so n^2 lookups. Isn't it possible to automatically disable the palette automatically for images with a bit depth of 16 bits or more? I'm not aware of any image format that uses palettes at those bit depths (and even if there are such formats, they are at least not common in general use cases). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
In our previous episode, Mattias Gaertner said: > > for reading it surely not appropriate regardless of using palette or not). > > I guess that some optimization may be reasonable because such pictures > > could be loaded and displayed (including conversion from true colour to > > 256 colours palette) faster even on a 486 machine... > Is there any size, where a palette image is fast? > > I think this is a newbie trap and the default for UsePalette should be > changed. Not just newbies :-) http://bugs.freepascal.org/view.php?id=17621 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, May 30, 2011 at 10:16 PM, Marco van de Voort wrote: > > http://bugs.freepascal.org/view.php?id=17621 > Indeed, I was remembering that too =) And also, I have a program which loads a huge image (20MB) using TPortableNetworkGraphics and it takes minutes to load the image. I have simply supposed that it was because of the file system usage, but now I am starting to think that maybe the fcl-image pallete causes the slowness. So I have to suggest: Is there a convincing reason for having Pallete set to true by default? What do you think about the trivial solution of setting it off by default? -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] English lazarus book available.
Hello, For the interested: I got news from the editor (chairman of the Dutch Pascal User Group) that the Lazarus book "Lazarus Complete Guide" is now available for sale. It can be purchased on-line from: http://www.blaisepascal.eu/index.php?actie=./subscribers/subscription_mainpageUKPaypalPage2 It is a translation of the original German "Lazarus" book, published by C&L (which is by now in its second edition!). Several of the core FPC/Lazarus developers have participated in the writing of this book. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, May 30, 2011 at 10:22 PM, Felipe Monteiro de Carvalho wrote: > So I have to suggest: Is there a convincing reason for having Pallete set to > true by default? What do you think about the trivial solution of setting it > off by default? It seems I have opened a hornets nest. :) But from the many replies, it seems everybody expects UsePalette to be False by default (instead of what it is now True). Maybe a new default should be considered. -- Ben. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, 30 May 2011, Felipe Monteiro de Carvalho wrote: On Mon, May 30, 2011 at 10:16 PM, Marco van de Voort wrote: http://bugs.freepascal.org/view.php?id=17621 Indeed, I was remembering that too =) And also, I have a program which loads a huge image (20MB) using TPortableNetworkGraphics and it takes minutes to load the image. I have simply supposed that it was because of the file system usage, but now I am starting to think that maybe the fcl-image pallete causes the slowness. So I have to suggest: Is there a convincing reason for having Pallete set to true by default? What do you think about the trivial solution of setting it off by default? It is now off by default. Committed in revision 17613. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Missini graph unit
On 05/30/2011 12:25 PM, Elio Fabri wrote: I tried ptcgraph by a mere change of names, and it works, more or less. However, the graph unit still appears in the doc, whereas I cant't find no doc for pctgraph. Some help? It's a new unit (first included with fpc 2.4.4) and therefore not yet mentioned in the fpc docs. It should work like a normal TP7-compatible graph unit. There's also a 'ptccrt' unit, which works together with ptcgraph and allows reading keyboard input. Internally, they both use the PTCPas graphics library: http://ptcpas.sourceforge.net/ But this shouldn't matter much from a user point of view (ptcpas requires no extra dlls or .so files) The standard linux 'graph' unit uses svgalib (which is outdated and probably does not run on modern graphics hardware) and is only available for i386. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is FPImage dog slow in reading jpeg's?
On Mon, 30 May 2011 23:24:30 +0200 (CEST) Michael Van Canneyt wrote: > > > On Mon, 30 May 2011, Felipe Monteiro de Carvalho wrote: > > > On Mon, May 30, 2011 at 10:16 PM, Marco van de Voort > > wrote: > > http://bugs.freepascal.org/view.php?id=17621 > > > > > > Indeed, I was remembering that too =) > > > > And also, I have a program which loads a huge image (20MB) using > > TPortableNetworkGraphics and it takes minutes to load the image. I have > > simply supposed > > that it was because of the file system usage, but now I am starting to > > think that maybe the fcl-image pallete causes the slowness. > > > > So I have to suggest: Is there a convincing reason for having Pallete set > > to true by default? What do you think about the trivial solution of setting > > it > > off by default? > > It is now off by default. > > Committed in revision 17613. Great. :) Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : RE : RE : RE : [fpc-pascal] support for usinganactivex
Thanks, I'll try installing a more recent fpc and lazarus...
2011/5/30 Ludo Brands :
> I created a small automation object with following IDL (part of it):
>
> interface ItestAX: IDispatch
> {
> [
> propget,
> id(0x0001)
> ]
> HRESULT _stdcall Devices([out, retval] IDevices ** Value );
> };
>
> interface IIDevices: IDispatch
> {
> [
> propget,
> id(0x)
> ]
> HRESULT _stdcall Device([in] long Idx, [out, retval] IDevice ** Value );
> [
> propget,
> id(0x0002)
> ]
> HRESULT _stdcall Count([out, retval] long * Value );
> };
>
> interface IIDevice: IDispatch
> {
> [
> propget,
> id(0x0001)
> ]
> HRESULT _stdcall Name([out, retval] BSTR * Value );
> };
>
> This matches pretty much the interface you described earlier. Note the
> id(0x) which makes Device the default member of IIDevices. This is
> the same as id(DISPID_VALUE) in your case.
>
> Now, the following lines do work for me to get the Name member of IIDevice
> (ActX,a,b:variant;s:string):
>
> ActX:=CreateOleObject(MyTestControl);
> a:=ActX.Devices;
> b:=a.Device[3];
> s:=b.Name;
> b:=ActX.Devices.Device[3];
> s:=b.Name;
> b:=ActX.Devices[3];
> s:=b.Name;
>
> Note that the default member does work correctly:
> Devices.Device[3]===Devices[3].
>
> I'm using fpc 2.5.1 svn 17599.
>
> Ludo
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
