On Thu, 8 Dec 2016, Mattias Gaertner wrote:
On Thu, 8 Dec 2016 14:09:53 +
Graeme Geldenhuys wrote:
On 2016-12-08 14:01, Mattias Gaertner wrote:
That would be a 64bit per pixel image, wasting a lot of memory.
Why FPImage uses 64bit per pixel is beyond me! The original author of
FPImag
On 2016-12-08 16:24, Mattias Gaertner wrote:
> Even rocket scientists can't read minds.
:-)
> Will you create the patch or should I?
I'll create a patch.
Regards,
Graeme
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fre
On Thu, 8 Dec 2016, fredvs wrote:
Hello.
In a audio library, it uses a buffer to record audio.
There is a main loop that store the audio-data given by the audio-input
device into the buffer.
For this TFileStream.WriteBuffer() is used.
Ok, all works well.
But I noted that the ram used incre
On Thu, 8 Dec 2016 15:15:55 +
Graeme Geldenhuys wrote:
> On 2016-12-08 14:22, Mattias Gaertner wrote:
>[...]
> It's not rocket science. ;-)
Even rocket scientists can't read minds.
Will you create the patch or should I?
Mattias
___
fpc-pascal mai
On 2016-12-08 14:22, Mattias Gaertner wrote:
>> > This might be a good solution. Some ready-made event handlers.
> Any idea how that should look like?
In the TFPReaderTiff class, define public methods (possibly marked as
virtual) as follows Here's one example:
procedure TFPReaderTiff.CreateC
On Thu, 8 Dec 2016 14:09:53 +
Graeme Geldenhuys wrote:
> On 2016-12-08 14:01, Mattias Gaertner wrote:
> > That would be a 64bit per pixel image, wasting a lot of memory.
>
> Why FPImage uses 64bit per pixel is beyond me! The original author of
> FPImage clearly thought he/she saw something
On 2016-12-08 14:01, Mattias Gaertner wrote:
> That would be a 64bit per pixel image, wasting a lot of memory.
Why FPImage uses 64bit per pixel is beyond me! The original author of
FPImage clearly thought he/she saw something cool in that, but 99.9%
of the time *nobody* needs that. It's causin
On Thu, 8 Dec 2016 12:12:27 +
Graeme Geldenhuys wrote:
> On 2016-12-07 17:47, Mattias Gaertner wrote:
> >> > t := TFPReaderTiff.Create;
> > t.OnCreateImage:=@...
> >
>
> Thanks that solved it.
>
> But why can't TFPReaderTiff do that for us, or at least have a default
> implementation
Hello.
In a audio library, it uses a buffer to record audio.
There is a main loop that store the audio-data given by the audio-input
device into the buffer.
For this TFileStream.WriteBuffer() is used.
Ok, all works well.
But I noted that the ram used increase at each loop and when the max ram i
On 2016-12-07 17:47, Mattias Gaertner wrote:
>> > t := TFPReaderTiff.Create;
> t.OnCreateImage:=@...
>
Thanks that solved it.
But why can't TFPReaderTiff do that for us, or at least have a default
implementation (override'able by developers if really needed).
Regards,
Graeme
--
fpGUI Tool
David Emerson wrote:
Graeme Geldenhuys wrote:
Martin Schreiber wrote:
That happens with every reallocmem() with FPC memory manager so using a
getmem() block instead of a dynamic array has no advantage in this
Maybe a good old linked list implementation is the best performer then.
Back to the
11 matches
Mail list logo