On Wednesday 22 August 2007 19:18, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> >> Why is calling via a procvar very much slower than a normal call ?
> >> It's just an extra memory fetch (hopefully in cache) ?
> >
> > Jonas meant that each pixel is drawn separately. The procvar is not
> > t
Jonas Maebe wrote:
On 23 Aug 2007, at 00:00, Marc Weustink wrote:
Target by target and tonight I came to the last: OSX.
And there I noticed that the ppcppc 2.1.5 compiler stopped searching
for Lower/Uppercase unitname variants, so it cannot compile my lazarus
sources anymore (while 2.0.4 hap
On 23 Aug 2007, at 00:00, Marc Weustink wrote:
Target by target and tonight I came to the last: OSX.
And there I noticed that the ppcppc 2.1.5 compiler stopped
searching for Lower/Uppercase unitname variants, so it cannot
compile my lazarus sources anymore (while 2.0.4 happily does)
Is ther
On 22 Aug 2007, at 23:36, Christian U. wrote:
Is there an easy way to uninstall fpc in MacOS X ?
Not really. An uninstall facility is a glaring omission in Apple's
Mac OS X installer infrastructure (even though you can mark installer
packages as "uninstallable" when creating them, there i
Hi,
For Lazarus development I share my lazarus sources on a nfs and samba
export, so I have the same source tree for Win32/64/CE, Linux and OSX
development. Samba is used for windows, nfs for the others. The last
months I've been switching my development compiler from 2.0.4 to 2.1.5
Target by
Is there an easy way to uninstall fpc in MacOS X ?
I have installes an snapshot package from lazarus page with fpc 2.1.5.
regards
Christian
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 22 Aug 2007, at 20:59, Evgeniy Ivanov wrote:
Hm... I've tried such thing:
procedure sdlgraph_HLine(x,x2,y: smallint);
begin
SDL_DrawLine(screen,X,y,x2,y,255);
SDL_Flip(screen);
end;
The same. I will try to find the true way, but I'm not sure that it
can be
without locking overhead. I
On 22 Aug 2007, at 21:18, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Why is calling via a procvar very much slower than a normal
call ? It's
just an extra memory fetch (hopefully in cache) ?
Jonas meant that each pixel is drawn separately. The procvar is
not the issue.
Before me
Michael Van Canneyt wrote:
>> Why is calling via a procvar very much slower than a normal call ? It's
>> just an extra memory fetch (hopefully in cache) ?
>
> Jonas meant that each pixel is drawn separately. The procvar is not the issue.
Before me going too far in unknown territory, but isn't tha
On Wed, 22 Aug 2007, Micha Nelissen wrote:
> Jonas Maebe wrote:
> > No, it is still slow. You indeed do not have locking overhead, but you
> > are still calling nonBuf_DirectPutPixel via a procvar for each pixel
> > which has to be drawn (from hlinedefault). That is still very slow.
>
> Why is
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:
>
> > 2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
> >>
> >>
> >> It is because you do not redirect the line drawing directly to SDL,
> >> but instead use the default line drawing routines. Those are in
Jonas Maebe wrote:
> No, it is still slow. You indeed do not have locking overhead, but you
> are still calling nonBuf_DirectPutPixel via a procvar for each pixel
> which has to be drawn (from hlinedefault). That is still very slow.
Why is calling via a procvar very much slower than a normal call
On 22 Aug 2007, at 18:24, Evgeniy Ivanov wrote:
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
It is because you do not redirect the line drawing directly to SDL,
but instead use the default line drawing routines. Those are indeed
very slow, because they call a procedural variable (directputpix
On Wed, 22 Aug 2007, Darius Blaszijk wrote:
> Here's my last patch for now for fpmkunit. As it seems all commands are fixed
> now. I need to add the last bit to the documentation, but it's pretty up to
> date as it stands.
>
> - replace MatchesMask function by IsWild function from StrUtils
> -
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> It is because you do not redirect the line drawing directly to SDL,
> but instead use the default line drawing routines. Those are indeed
> very slow, because they call a procedural variable (directputpixel)
> for each pixel which has to be drawn).
On 22 Aug 2007, at 12:26, Evgeniy Ivanov wrote:
Bar3D is indeed one of the few routines which cannot be hooked
currently. As long as you hook the line drawing it should be plenty
fast though.
No, I tryed. It is in the test.pas. It works very very slow.
It is because you do not redirect the
2007/8/22, Jonas Maebe <[EMAIL PROTECTED]>:
>
>
> Congratulations! Just one note: please do not make it GPL, because
> that would mean anyone using that unit would have to make their
> program also GPL. Instead, please change the text at the top to
> something like this:
>
> ***
> Copyright (c
17 matches
Mail list logo
