Hi All,
In my Lazarus application I use a TPanel descendant component (TMyPanel)
which have subpanels (TMySubPanel) which are TPanel descendants also.
The subpanels accessed through a TList. If add a new subpanel into the
main panel added to the list with TList.Add if remove a subpanel from it
Yes, it is puzzling. Different pointer sizes, compilers, OS, 32/64 bit
library dependencies, can be potential causes.
Again, note that I compiled the example on a CentOS 7, 64bit Linux with
Lazarus 1.5 + fpc 3.0.1
I can also confirm that the test program compiles and works fine on
Ubuntu 16.
>If you are already on a win64 machine then your default target CPU should
>already be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?
Correction:
I start with fpc-3.0.2.i386-win32 because there is no precompiled version for
win64 of freepascal I tried to compile it myself is it's jus
>It is unclear to me whether you are on a win32 or win64 OS?
I am on Windows 10 x64 OS
>If you are already on a win64 machine then your default target CPU should
>already be x86_64. why do you need fpc-3.0.2-cross-i386-win32-win64?
fpc-3.0.2-cross-i386-win32-win64 is to be able to compile as a wi
While in lazarus open agg_rasterizer_scanline_aa.pas, go ro line 611
press Ctr and click on ptrcomp. It should open agg_basics.pas, the
comment may apply to your situation.
It is unclear to me whether you are on a win32 or win64 OS? If you are
already on a win64 machine then your default targe
>Noting your problems with compilation, you may want to consider using Lazarus
>IDE as well.
I have just installed Lazarus but still can't get the
aggpas_ptcgraph_output.pas sample program to run when compiled for x64.
Here is what I have done.
Downloaded and installed lazarus-1.6.0-fpc-3.0.0
>Looks like it may be something specific to your setup. In my tests I used
>Lazarus 1.5 as IDE and fpc 3.0.1 on Linux. Crosscompiled example ran on Win7
>64 bit.
>So there are already differences with your environment. Noting your problems
>with compilation, you may want to consider using Lazar
Looks like it may be something specific to your setup. In my tests I
used Lazarus 1.5 as IDE and fpc 3.0.1 on Linux. Crosscompiled example
ran on Win7 64 bit. So there are already differences with your
environment. Noting your problems with compilation, you may want to
consider using Lazarus ID
>I've tested the example on 64 bit linux as a native application as well cross
>compiled for a x86_64 windows target. Worked fine in both Wine and on a Win64
>machine.
>In my experience, the one dependency that AggPas has potential to fail may be
>related to the freetype library. If you plan to
Thanks for the help with this
> 1) the ideal way would be to specify the rgb order of a pixel format in the
> Agg_2D constructor. The m_pixFormat
> has a m_order field with the type order_type defined in agg_color.pas; have
> not figured it yet
>2) knowing the R and B channels are swapped, you
> Also, the image is flipped on
>the Y axis compared to the original example. The small green square is in the
>upper left corner of test.png, but it is in the lower left corner of
>aggpas_ptcgraph_output.pas
It appears there is some ambiguity on whether 0,0 should be the lower left of
upper
There is a minus sign in the call:
agg^.attach(@graph_buffer.data, IMAGE_WIDTH, IMAGE_HEIGHT,
-(IMAGE_WIDTH * RGB_WIDTH))
Removing it will flip the Y axis.
With regard to color, there may be two options:
1) the ideal way would be to specify the rgb order of a pixel format in
the Agg_2D con
I've just realized that the red and blue channels are reversed. The sample
program aggpas_ptcgraph_output.pas has the star filled in with a red fade
and a blue series of random lines while the original test.png file had a
blue fade in the star with red random lines. Also, the image is flipped on
On Tue, Jun 13, 2017 at 5:20 PM, Michael Van Canneyt
wrote:
> However, this method of loading an image depends on the order of the uses
> statements: each registered reader is asked in turn whether it recognizes
> the stream.
The unit IntfGraphics in LCL does not have unit FPReadPNM in its uses c
On Tue, 13 Jun 2017, Juha Manninen wrote:
The class TFPCustomImage and its usage has apparently changed in FPC
3.0.2 (and trunk) compared to FPC 3.0.
This issue:
https://bugs.freepascal.org/view.php?id=32005
is marked for TLazIntfImage (in LCL) but actually the problematic
procedure LoadFrom
The class TFPCustomImage and its usage has apparently changed in FPC
3.0.2 (and trunk) compared to FPC 3.0.
This issue:
https://bugs.freepascal.org/view.php?id=32005
is marked for TLazIntfImage (in LCL) but actually the problematic
procedure LoadFromStream is in TFPCustomImage.
Please read my no
16 matches
Mail list logo
