Implementing AggPas with PtcGraph

classic Classic list List threaded Threaded
103 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Tomas Hajny-2
On Thu, June 15, 2017 16:06, James Richters wrote:
 .
 .
>> 3) Make sure you always rebuild the unit depending on the program you
>> want to compile (Compile -> Build).
>
> Is there a way to force this with the command line? (same as Compile >
> build from the IDE) ?

Yes, of course - it's the option '-B'.


 .
 .
> Oh, I see the issue here.   So If I were to write a unit that I wanted
> Programs to share, but have various options, I may be better off to define
> a variable in the unit and let the programs change the variable depending
> on what they want.... with the compiler directives, it's actually leaving
> out parts altogether, so you need to re-compile the unit if you want to
> change it... makes smaller files than always including things you don't
> want to use.
 .
 .

Yes, exactly (plus there are some more reasons, like that you want to
reduce unneeded dependencies which may not be fulfilled, etc.).

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
In reply to this post by Graeme Geldenhuys-6
>And if you look in the "develop" branch of fpGUI, there is an even later
>AggPas version - last updated a month ago

I downloaded the fpGUI repository to have a look at it, and thought I would see if any of the things I was encountering with it were addressed yet.   Sure enough, I found

{$IFDEF AGG2D_USE_FREETYPE}
  {$UNDEF AGG2D_USE_WINFONTS}
{$ENDIF}

Already there,  actually formatted exactly the way I did to get it to compile.  So I went back in the history of the file to see when that was added, and I found it.... 4 years ago!
This was really puzzling because I had to fix the version included with fpGUI 1.4.1 which was from 2015.  

Well looking more closely, I discovered there are 2 units... agg2D.pas and agg_2D.pas.   well agg2D.pas is all the way at the bottom of all the agg_* units so I never knew it was there.... so when I specifically looked for agg_2d.pas (which is the one I was using)  I found that it also was fixed, but only 11 months ago... after 1.4.1 was released.  

So mystery solved... but.........

It raises a new question...
What is the difference between agg2D.pas and agg_2D.pas and which one do I want to be using?  

Also when looking through the fpGUI as well as the Freepascal repositories,  there are just thousands of commits.  looking at all those commits gives a real appreciation for the amount of work that has gone into the project.   So a huge thank you goes out to everyone who has worked so hard to make freepascal as awesome as it is, as well as the people who are such a tremendous help on this list.   Honestly if not for FreePascal, I would still be trying to put together Pentium 233 computers to run my old DOS applications on. (not fun, components are getting hard even to find on ebay now)   I just don't have time to do a massive re-write all at once, and FreePascal let me drop in my Turbo Pascal programs and pretty much just run them.  

James

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Tomas Hajny-2
On 2017-06-15 13:34, Tomas Hajny wrote:
> Not quite - the text-mode IDE doesn't invoke fpc.exe binary (it has the
> compiler built-in) and it passes the options as defined in the respective
> IDE dialogs.


Thanks Tomas for correcting me. I wasn't 100% sure about the behaviour
of a compiled-in compiler.


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-06-15 15:06, James Richters wrote:
> I don't like modifying units that are part of a package
> because then I would need to remember how I modified them when a new
> version is released or have to figure out what's going on all over
> again.

I use Git for just about any source code I work with. I even let Git
manage a SubVersion repository. I also often have my own "custom
changes" in 3rd party code. With Git I simply create a "custom-mods"
branch where I commit all my personal preferences. As the 3rd party code
moves forward, I can move my whole "custom-mods" branch forward to by
using the Git command "rebase". It's very little effort, and I have
dragged some of my custom-mods branches forward since around 2010 (in
various 3rd party code).


>> 3) Make sure you always rebuild the unit depending on the program
>> you want to compile (Compile -> Build).
> Is there a way to force this with the command line?

Yes.  The -B compiler command line parameter.


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-06-15 22:17, James Richters wrote:
> I specifically looked for agg_2d.pas (which is the one I was using)
> I found that it also was fixed, but only 11 months ago... after 1.4.1
> was released.

Yes, that's my bad. The agg_2d.pas unit was lagging behind for a while,
because I never really used it until about 12-18 months ago.


> So mystery solved... but.........

We all love a mystery. ;-)


> It raises a new question... What is the difference between agg2D.pas
> and agg_2D.pas and which one do I want to be using?

Yeah, probably not the best naming convention.

The agg_2D.pas unit is a 100% non-GUI unit. It is meant for console or
web (eg: CGI) style applications. No GUI toolkit dependencies are required.

The "agg2D.pas" unit depends on fpGUI Toolkit, because it implements a
fpGUI Canvas that uses AggPas for all it's 2D drawing routines. So it's
a descendant of TfpgCanvasBase (a fpGUI class).



Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Stefan V. Pantazi
In reply to this post by Zaaphod
I was waiting for the right time to also offer my sincere thanks to all
teams and individual contributors. I have been using fpc and Lazarus IDE
for quite some years now and I am very pleased with the constant
progress and improvement of these development tools. I have enjoyed
reading and learned a lot on these mailing lists as well. My hope is
that contributions continue for many years to come and that the
community remains helpful as it has always been.

Stefan

>
> Also when looking through the fpGUI as well as the Freepascal repositories,  there are just thousands of commits.  looking at all those commits gives a real appreciation for the amount of work that has gone into the project.   So a huge thank you goes out to everyone who has worked so hard to make freepascal as awesome as it is, as well as the people who are such a tremendous help on this list.   Honestly if not for FreePascal, I would still be trying to put together Pentium 233 computers to run my old DOS applications on. (not fun, components are getting hard even to find on ebay now)   I just don't have time to do a massive re-write all at once, and FreePascal let me drop in my Turbo Pascal programs and pretty much just run them.
>
> James
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
In reply to this post by Graeme Geldenhuys-6
>I use Git for just about any source code I work with.
I've just recently started using GIT, and have been using it for my own applications.  My solution until now has been to duplicate any units that needed modification in with my source code so it would show up in my GIT repository.  But I like the idea of just maintain my own local copy and put a custom branch that I can keep maintained easier.. and who knows maybe I'll come up with something worth submitting to the project.

>We all love a mystery. ;-)
Especially once it's solved

>Yeah, probably not the best naming convention.
Perhaps some comments at the top of both units explaining the difference and also mentioning the other unit exits would save some confusion

>The agg_2D.pas unit is a 100% non-GUI unit. It is meant for console or
>web (eg: CGI) style applications. No GUI toolkit dependencies are required.

Sound like I was using the correct unit anyway for my console apps

James

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
I've been able to use windows fonts with aggpas with the following code:
 
   agg^.Font('ConsolaB.ttf' ,45 );
   agg^.Text(300 ,100 ,'Text Here' );

and it works fine if I copy the font to the same folder as my program.  I'm wondering how I can just use standard windows fonts without copying them... but not assuming windows is installed in c:\windows

agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 )
works fine, but as I mentioned I can't be sure windows is installed in C:\Windows

I would like to do something like:
agg^.Font('%windir%\Fonts\ConsolaB.ttf' ,45 );

but of course that won't work because the %windir% variable only works in batch files.  

Is there some other way I can capture the install directory of windows, or the system so I can make this work properly?


Also, while I was tinkering with this,  I also wanted to see what differences there are between Freetype and Windows True Type fonts, and I noticed something odd..
If I compile with {$DEFINE AGG2D_USE_FREETYPE }  it works fine... but if I compile with it commented out,  it does work, and I get text on the screen, but the font is not the one I selected.  It seems to be a default font that I can't change. Does the font need to be defined differently if using Win32 TT font engine?    I am using the current 'develop' branch of fpGUI version of aggpas now.  I have not tried it with the release version.

I'm also wondering if there is a way to specify the font by the name used by windows applications, or is that more complicated than it is really worth?

James



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

DaWorm
On Fri, Jun 16, 2017 at 1:49 PM, James Richters <[hidden email]> wrote:

I would like to do something like:
agg^.Font('%windir%\Fonts\ConsolaB.ttf' ,45 );

 
You should be able to use SHGetFolderPath() with CSIDL_WINDOWS.  Not sure you can always count on Fonts being a subfolder of that, though.


You may be able to use CSIDL_FONTS or FOLDERID_Fonts as well.


Not sure if any are defined in FPC, but should be easy to create/import if not.

Jeff.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod

>You may be able to use CSIDL_FONTS or FOLDERID_Fonts as well.

 

Thank you for pointing me in the right direction.   I was able to get CSIDL_FONTS to work.  Getting the actual fonts folder is a better idea than assuming it’s in a \Fonts directory

 

I found an example on how to obtain the path from here:

http://wiki.lazarus.freepascal.org/Windows_Programming_Tips

under “Getting special folders (My documents, Desktop, local application data, etc)”

 

Here is how I was able to get it to work.  I’m wondering if there is a better way to define my variables. I tried just making Font2Use a string but it didn’t compile;

 

Uses

  shlobj,

..

Var

  Font2Use,FontPath: Array[0..MaxPathLen] of Char; //Allocate memory

..

   SHGetSpecialFolderPath(0,FontPath,CSIDL_FONTS,false);

   writeln('Fonts: ' + FontPath);

   font2use:=FontPath+'\segoescb.ttf';

   Writeln(Font2use);

   agg^.Font(font2use ,45 );

..

 

 

James


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-06-16 18:49, James Richters wrote:
> agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 )
> works fine, but as I mentioned I can't be sure windows is installed in C:\Windows

When you use the Windows GDI font engine, you don't have to specify the
location of the font - that is done for you in the font engine. Also you
specify the font name like windows programs do, you don't specify the
font filename.

For example:

   agg^.LineWidth(1);
   agg^.Font('Consola' ,45, True); // Bold
   agg^.Text(300 ,100 ,'Consola font here.' );
   agg^.Font('Courier New' ,45, False, True );  // Italics
   agg^.Text(300 ,150 ,'Courier New font here.' );


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
>When you use the Windows GDI font engine, you don't have to specify the location of the font - that is done for you in the font engine.
> Also you specify the font name like windows programs do, you don't specify the font filename.

Thank you the information

I finally partially figured out the red / blue color problem.  
After single stepping through tons of the aggpas code for hours (it's quite complicated even to draw a line) with a sample program that just made a red line at the top, I discovered that it's actually doing everything exactly correct!   The problem is not with rendering with rgb565,  the problem is something in the original that was patched with the setcolor function:

Line 122 of agg_color pas has:
constructor rgba8.Construct;
begin
 b{*}:=int8u(r_ );
 g:=int8u(g_ );
 r:=int8u(b_ );
 a:=int8u(a_ );

end;

This switches red and blue... if I correct it to:
constructor rgba8.Construct;
begin
 b{*}:=int8u(b_ );
 g:=int8u(g_ );
 r:=int8u(r_ );
 a:=int8u(a_ );

end;

now my colors with rgb565 are correct.     Since this is no logical reason to make b:=R_ and r:=B_ it seems more likely that with the rgba format somewhere along the way someone got lazy and just switched red and blue instead of fixing the pixelformat.

It became obvious that the original was the thing that was backwards, not the RGB565 patch because I kept stepping through things like:
constructor aggclr.Construct(rgba : rgba8 );
begin
 v:=(rgba.r * 77 + rgba.g * 150 + rgba.b * 29 ) shr 8;
 r:=rgba.r;
 g:=rgba.g;
 b:=rgba.b;
 a:=rgba.a;

end;
When I evaluated the variables
R=0
G=0
B=255
A=255

But I defined a RED line, not a blue one.  

I used
agg^.lineColor($FF, 0, 0, 255);

and according to:

procedure Agg2D.lineColor(r ,g ,b : unsigned; a : unsigned = 255 );
var
 clr : Color;

begin
 clr.Construct(r ,g ,b ,a );
 lineColor    (clr );

end;

This should be red.

Every other function or procedure I came across with elements for red, green and blue kept coming up like this, so technically are incorrect.   Where the inconsistency come from to fix it properly.  For now I just made a compiler directive {$DEFINE AGG2D_USE_RGB565 } and use it to fix things in both agg_2D and agg_color.

I've committed these to a custom branch on my github fork of fpGUI at:
https://github.com/Zaaphod/fpGUI/tree/Zaaphod_Custom

I looked at the file history  in fpGUI and it looks like red and blue have been reversed like this since the initial import of aggpas into fpGUI,  when I look at the original example agg2dconsole.dpr, it has in it:
      c.red := getBufItemAsWord(2);
      c.green := getBufItemAsWord(1);
      c.blue := getBufItemAsWord(0);
      c.alpha := getBufItemAsWord(3);

but it should have been

      c.red := getBufItemAsWord(0);
      c.green := getBufItemAsWord(1);
      c.blue := getBufItemAsWord(2);
      c.alpha := getBufItemAsWord(3);

and would have been if constructor rgba8.Construct; was correct... instead it was just re-reversed to compensate for the error in agg_color.pas.   My point here is that it may be too late to just correct it now, because then everyone who has programs that already 'fix' the problem will then all be wrong, so I'm not sure what the best way to fix this is.

James





-----Original Message-----
From: fpc-pascal [mailto:[hidden email]] On Behalf Of Graeme Geldenhuys
Sent: Sunday, June 18, 2017 12:32 PM
To: [hidden email]
Subject: Re: [fpc-pascal] Implementing AggPas with PtcGraph

On 2017-06-16 18:49, James Richters wrote:
> agg^.Font('C:\Windows\Fonts\ConsolaB.ttf' ,45 ) works fine, but as I  
> mentioned I can't be sure windows is installed in C:\Windows

When you use the Windows GDI font engine, you don't have to specify the location of the font - that is done for you in the font engine. Also you specify the font name like windows programs do, you don't specify the font filename.

For example:

   agg^.LineWidth(1);
   agg^.Font('Consola' ,45, True); // Bold
   agg^.Text(300 ,100 ,'Consola font here.' );
   agg^.Font('Courier New' ,45, False, True );  // Italics
   agg^.Text(300 ,150 ,'Courier New font here.' );


Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp _______________________________________________
fpc-pascal maillist  -  [hidden email] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Stefan V. Pantazi
Good find and great sleuth work.

It is possible that the original reason for switching R and B channels
was to make the agg color object more compatible with LCL which seems to
prefer BGR, order, but who knows... One obvious problem seems to be

function AggToLCLColor(const c: TAggColor): TColor;

in Agg_LCL, that relies for conversion on RGBToColor in the Graphics unit.

function RGBToColor(R, G, B: Byte): TColor;
begin
   Result := (B shl 16) or (G shl 8) or R;
end;

Anyway, a quick search of the agg source code shows that the rgba8
object is used only by a handful of units directly. Most agg units and
demos use the more complicated aggclr object to represent color. I tried
a few demos and seem unaffected by your fix. This explains why the bug
was only clearly visible in your case, most of the other agg demos seem
indiferent to the bug. On the other hand, besides agg_2D there are
agg_fpimage, Agg2D (the one that integrates with LCL) that also use the
rgba8 (through the TAggColor alias) and are clearly affected by the R
and B swap when using canvas methods that involve the TAggColor object
(e.g., AggClearAll, AggClearClipBox, etc). These would need to be
updated as well. As an example, after your fix, the call
canvas.AggClearAll(255,0,0) to TAggFPCanvas.AggClearAll(const r ,g ,b :
byte; a : byte = 255 ) produces a blue background, which is clearly wrong.

On 06/18/2017 08:35 PM, James Richters wrote:

>
> I finally partially figured out the red / blue color problem.
> After single stepping through tons of the aggpas code for hours (it's quite complicated even to draw a line) with a sample program that just made a red line at the top, I discovered that it's actually doing everything exactly correct!   The problem is not with rendering with rgb565,  the problem is something in the original that was patched with the setcolor function:
>
> Line 122 of agg_color pas has:
> constructor rgba8.Construct;
> begin
>  b{*}:=int8u(r_ );
>  g:=int8u(g_ );
>  r:=int8u(b_ );
>  a:=int8u(a_ );
>
> end;
>
> This switches red and blue... if I correct it to:
> constructor rgba8.Construct;
> begin
>  b{*}:=int8u(b_ );
>  g:=int8u(g_ );
>  r:=int8u(r_ );
>  a:=int8u(a_ );
>
> end;
>
> now my colors with rgb565 are correct.     Since this is no logical reason to make b:=R_ and r:=B_ it seems more likely that with the rgba format somewhere along the way someone got lazy and just switched red and blue instead of fixing the pixelformat.
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-06-16 01:51, James Richters wrote:
>> Yeah, probably not the best naming convention.
 >
> Perhaps some comments at the top of both units explaining the
> difference and also mentioning the other unit exits would save some
> confusion


I have applied such a change. So far only to the Agg2D and agg_2D units,
but I'll do the same to the rest of the units shortly.

I'm also strongly considering renaming the "render/software/" directory
to "render/aggpas/". I'll mull this over for another day or two.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
In reply to this post by Zaaphod
On 2017-06-19 01:35, James Richters wrote:

> The problem is not with rendering with rgb565,  the problem is something in the original that was patched with the setcolor function:
>
> Line 122 of agg_color pas has:
> constructor rgba8.Construct;
> begin
>  b{*}:=int8u(r_ );
>  g:=int8u(g_ );
>  r:=int8u(b_ );
>  a:=int8u(a_ );
>
> end;


WOW, well spotted - and how that went unnoticed for all these years is
beyond me. Well done for bringing it to our attention.

That is a fundamental bug in AggPas, and something I'll be fixing
immediately in fpGUI's repository. As for the affects on other code and
programs. I'll do some testing to see what exact affect it has, and then
add some notes in the CHANGELOG document describing code-breaking
changes and recommended fixes.

I have always been in the mind that fundamental code and API's should be
100% correct, and fixed promptly when a bug is found. Applications that
are affected by such changes need to be updated - that's the bottom
line. No point in continue maintaining buggy code and API's and
guaranteed that things will just get worse in the future - if not
immediately fixed.

Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
In reply to this post by Graeme Geldenhuys-6
>I have applied such a change. So far only to the Agg2D and agg_2D units, but I'll do the same to the rest of the units shortly.
That will be a great help.   Might I suggest mentioning the existence and use of Agg2D in agg_2D and vice versa?  Something like:

agg_2D
This unit has NO graphical toolkit dependencies, so is ideal for console or web based (server side) projects.    For the graphical full toolkit version, see Agg2D.pas

Agg2D:
If you do not need to graphical toolkit (for example for console or web based projects, this dependency can be avoided by using agg_2D.pas

Something to that effect.  My reasoning of mentioning each in the other is because the names are so similar, yet it's difficult to know the other exists because agg2D is all the way at the bottom of all the agg_ units, while agg_2D is at the top of them all.   Mentioning the other unit and it's use may help clarify things.

I also think you have made enough changes to it to warrant version number changes.  


>I'm also strongly considering renaming the "render/software/" directory to "render/aggpas/". I'll mull this over for another day or two.

I like the proposed directory name.  I wonder if it really needs 2 directories, why not just render-aggpas/ or aggpas-render/  ?


>That is a fundamental bug in AggPas, and something I'll be fixing immediately in fpGUI's repository. As for the affects on other code and programs.
>I'll do some testing to see what exact affect it has, and then add some notes in the CHANGELOG document describing code-breaking changes and recommended fixes.

Since there are going to be changes that require adjustments anyway, I wonder if it would make sense to just make agg_2D always require the pixel format in the constructor:

constructor Agg2D.Construct_PF(pixfmt:define_pixfmt);

It seems the original intention of aggpas was to have this flexibility but somewhere along the way things like rgba ended up getting hard coded into it.

>I have always been in the mind that fundamental code and API's should be 100% correct, and fixed promptly when a bug is found. Applications that are affected
>by such changes need to be updated - that's the bottom line. No point in continue maintaining buggy code and API's and guaranteed that things will just get worse
>in the future - if not immediately fixed.

I agree with you, and if the changes for common issues are well documented then it seems to be the best solution.  I was trying to think of a way to adjust the unit and maintain backward compatibility, but it just ends up making a mess of everything.  Better off to just fix it then fix any programs as needed instead of having an even bigger and more confusing mess that no one will remember why it's like that in 5 years.

James

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Graeme Geldenhuys-6
On 2017-06-20 11:17, James Richters wrote:
> That will be a great help.   Might I suggest mentioning the existence
> and use of Agg2D in agg_2D and vice versa?  Something like:

Ah yes, I forgot about that. I'll add it now.


> I also think you have made enough changes to it to warrant version
> number changes.

After moving AggPas into the fpGUI repository, I don't consider it a
separate "project" as such - even though it can still be used
independent from fpGUI. So the original AggPas version numbering is of
no concern to me any more, it will now follow the versions of fpGUI itself.

The unit header comment does mention that I forked it from the original
2.4 RM3 AggPas, but that things diverged from there.


>> I'm also strongly considering renaming the "render/software/"
>> directory to "render/aggpas/". I'll mull this over for another day
>> or two.
>
> I like the proposed directory name.  I wonder if it really needs 2
> directories, why not just render-aggpas/ or aggpas-render/  ?

The 2 part directory names is because other Canvas renderers will and
can be added to fpGUI. eg: Locally I already have a user contributed
Cairo canvas renderer which lives in the "render/cairo/" directory, but
has not been made public yet in the Github/SourceForge repositories.
This is also why I think I should rename the "render/software/"
directory to "render/aggpas/" - it makes things much clearer.

I'm also thinking of refactoring the X11 and GDI canvas rendering code,
so they too live in the "render/*" directory hierarchy.

I also know of a user that is working on a OpenGL renderer for fpGUI.


> Since there are going to be changes that require adjustments anyway,
> I wonder if it would make sense to just make agg_2D always require
> the pixel format in the constructor:
>
> constructor Agg2D.Construct_PF(pixfmt:define_pixfmt);
>
> It seems the original intention of aggpas was to have this
> flexibility but somewhere along the way things like rgba ended up
> getting hard coded into it.

A very good point. I'll make a note to commit those changes too.


> Better off to just fix it then fix any programs as needed instead of
> having an even bigger and more confusing mess that no one will
> remember why it's like that in 5 years.

Exactly!



Regards,
   Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
>The 2 part directory names is because other Canvas renderers will and
>can be added to fpGUI.

Yes the directory structure makes more sense if there will be other
rendering options and render/aggpas/ also makes more sense than
render/software for the same reason.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Zaaphod
Is there a more direct way of getting aggpas to send its output to ptcgraph?   Currently I'm doing as in the demo programs and defining an array then using putimage() to transfer the array to ptcgraph... this is fairly slow, especially for fullscreen high resolution applications.   I'm trying to follow through some of the demos included with ptcpas and it seems they do something like:

{ lock surface pixels }
pixels := surface.lock;

Then using a pointer defined by pixels, the program makes changes to all the pixels, then

{ unlock surface }
surface.unlock;
and
{ copy surface to console }
 surface.copy(console, area, area);

send the changes to the screen.   I'm wondering if I can have aggpas work with the ptcgraph buffer directly, and maybe this would be more efficient than putimage()

Any ideas?

James

     

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Implementing AggPas with PtcGraph

Nikolay Nikolov-2


On 06/21/2017 08:05 PM, James Richters wrote:

> Is there a more direct way of getting aggpas to send its output to ptcgraph?   Currently I'm doing as in the demo programs and defining an array then using putimage() to transfer the array to ptcgraph... this is fairly slow, especially for fullscreen high resolution applications.   I'm trying to follow through some of the demos included with ptcpas and it seems they do something like:
>
> { lock surface pixels }
> pixels := surface.lock;
>
> Then using a pointer defined by pixels, the program makes changes to all the pixels, then
>
> { unlock surface }
> surface.unlock;
> and
> { copy surface to console }
>   surface.copy(console, area, area);
>
> send the changes to the screen.   I'm wondering if I can have aggpas work with the ptcgraph buffer directly, and maybe this would be more efficient than putimage()
>
> Any ideas?
It's more complicated than that, because ptcgraph does all these
operations in a separate thread. See the sources for ptcgraph and for
the ptcwrapper unit. However, putimage can be accelerated, although it
would still have to do a memory copy. This can be done, by implementing
and adding a PutImage procedure in the TModeInfo record, which is filled
in, during initialization. See the QueryAdapterInfo function in the
ptcgraph.pp. It does a series of:

InitMode(graphmode);
with graphmode do
begin
   ...
end;

And inside the 'with' statement, various procedure variables are set.
There, a PutImage routine can be added as well. Look at e.g.
ptc_putpixelproc_16bpp to see how the surface is locked and how the
actual drawing to the surface is done, inside ptcgraph.

Nikolay
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123456