Recent

Author Topic: Interfaces/Polymorphism  (Read 2587 times)

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #15 on: December 06, 2019, 11:47:39 am »
Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)

p.s. the cloud thing is a joke, I don't think that is related to cocoa.
More true than you think. Adobe were probably still sore about having to move from 68k to PPC!  Plus, the whole "Apple killed my Flash Player!" thing probably didn't help much.

I did poke around in the LCL, but it doesn't have what I need. My GUI is fully drawn with my own widgets and interface. I need to open a window, draw on it and catch mouse and keyboard action and that's about it. My Windows and Cocoa classes are only about 250 lines each, so should be quick work to translate over, although I'm going to do the full package rather than the "only what I need" version that I have now. All of the 2D drawing packages I've seen either rely on Carbon (extinct about now) or OpenGL (gently being shoved out the door by Metal as we speak.). What most people don't realize is that Cocoa and GDI are very highly optimized by their OSes and are extremely fast. I just removed all my GUI drawing optimizations as they were slowing things down compared to just redrawing the whole window everything. I don't see either APIs going anywhere anytime soon.  I was working on an OpenGL version of my GUI and when I got it running, it wasn't any faster since I still had to do the drawing in the cpu! (NanoVG, if memory serves.)

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #16 on: December 06, 2019, 11:48:11 am »
My first project will be porting over my VST plugin from C++ for both Mac and Windows
There is pl_AsioVST package which you can install via OPM which can help you to create VST plugins or ASIO applications. There are many included built in filters to built effects without much DSP knowledge. I am not quite sure, but I think it's only for Windows. It's a Lazarus port of this Delphi package: https://sourceforge.net/projects/delphiasiovst/
Thanks! I'll check it out!

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8590
  • FPC developer.
Re: Interfaces/Polymorphism
« Reply #17 on: December 06, 2019, 12:26:26 pm »
Carbon just worked, and was usable as fundament for long term libraries and frameworks. Even Adobe postponed the migration several times ( and eventually went with a cloud version)
More true than you think. Adobe were probably still sore about having to move from 68k to PPC!  Plus, the whole "Apple killed my Flash Player!" thing probably didn't help much.

I'm more talking about the 2003-2010 era, and then specially the (somewhat sure) rumour that there was a 64-bit Carbon but only for Adobe, not for users.

Quote
I did poke around in the LCL, but it doesn't have what I need. My GUI is fully drawn with my own widgets and interface. I need to open a window, draw on it and catch mouse and keyboard action and that's about it. My Windows and Cocoa classes are only about 250 lines each, so should be quick work to translate over, although I'm going to do the full package rather than the "only what I need" version that I have now.

If it is that small, I'd not bother with LCL either.

Quote
All of the 2D drawing packages I've seen either rely on Carbon (extinct about now) or OpenGL (gently being shoved out the door by Metal as we speak.). What most people don't realize is that Cocoa and GDI are very highly optimized by their OSes and are extremely fast.

Since Vista the drawing speeds of various operations change with GDI, and since the desktop became compositing, doublebuffering is often less needed.
However extremely fast is IMHO too much honor. I don't know COCOA, Metal and its progression good enough to judge performance.

I used Apple's for private work as *nix workstations up to 2005 partially because OS X was one of the first systems that got hibernation right, then with another architecture change and constant API breakage I gave up. And I'm glad I did when I see what followed. If app binaries can't be used for extended periods of time, for me there was little added value to e.g. BSD or Linux, which have the same problem. And Windows got hibernation reasonably right.

Quote
I just removed all my GUI drawing optimizations as they were slowing things down compared to just redrawing the whole window everything. I don't see either APIs going anywhere anytime soon.  I was working on an OpenGL version of my GUI and when I got it running, it wasn't any faster since I still had to do the drawing in the cpu! (NanoVG, if memory serves.)

Opengl is an art. Exact performance is card (+driver) dependent. But probably for normal windowing operations and control it doesn't matter.

I use opengl at work for "live" images of a vision system, and it is very fast specially on Intel APUs of generation 4000 and later (because GPU upload is suddenly magnitudes faster than with older or PCIexpress cards). Uploading, drawing (scaled) large images (e.g. 28MB)  and drawing 130.000 objects on top in the 0.1-1ms total range. 

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #18 on: December 06, 2019, 06:46:25 pm »

I'm more talking about the 2003-2010 era, and then specially the (somewhat sure) rumour that there was a 64-bit Carbon but only for Adobe, not for users.
I'd forgotten about that. I think Adobe really, really wanted a 64-bit version, but Steve told them it was dead and to go Cocoa. Once upon a time, I had a far better finger on Apple's pulse, being in the industry. Now all I have are fading memories...
Quote
Since Vista the drawing speeds of various operations change with GDI, and since the desktop became compositing, doublebuffering is often less needed.
However extremely fast is IMHO too much honor. I don't know COCOA, Metal and its progression good enough to judge performance.
I still have to use double-buffering, otherwise I get flickering. Now that I'm redrawing the whole thing, I could maybe drop it, but the bitblit procedure to copy the buffer is so fast, it just makes things look better at 60fps. IIRC, the Cocoa NSView is still automatically double-buffered behind the scenes.
Quote
I use opengl at work for "live" images of a vision system, and it is very fast specially on Intel APUs of generation 4000 and later (because GPU upload is suddenly magnitudes faster than with older or PCIexpress cards). Uploading, drawing (scaled) large images (e.g. 28MB)  and drawing 130.000 objects on top in the 0.1-1ms total range.
For most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8590
  • FPC developer.
Re: Interfaces/Polymorphism
« Reply #19 on: December 06, 2019, 07:35:55 pm »
For most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.

Actually that is wrong,  and old school opengl thinking. You can actually calculate the triangles from your own more highlevel definitions using the geometry shader. I do that all the time because I only show one in every <x>(*) images, so I write quite dense abstract info per image, and only one in every <x> is actually going to be displayed and the expansion is fairly free using the geometry shader.

p.s. x (*) typically being 5 or even more.

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #20 on: December 06, 2019, 08:58:50 pm »
For most graphics use cases, using OpenGL is a huge speed up. But for drawing 2D lines, circles, and text, you still have to make the triangles. Lots of triangles.

Actually that is wrong,  and old school opengl thinking. You can actually calculate the triangles from your own more highlevel definitions using the geometry shader. I do that all the time because I only show one in every <x>(*) images, so I write quite dense abstract info per image, and only one in every <x> is actually going to be displayed and the expansion is fairly free using the geometry shader.

p.s. x (*) typically being 5 or even more.
Oh, okay, I see. Somebody should tell the rest of the world, though!   ;D

Honestly, it's been a couple of years since I did the work and nothing I looked at used the shaders to do this. I was about ready to adopt the OpenGL version (since it obviate the need for me to do any Windows programming) when I found out Apple was sundowning their OpenGL support, which has always been dodgy at best.

I just wish there was one graphics standard we programmers could use and leave it up to the OSes to implement it, either offloading it to the GPU, or gracefully falling back to native where necessary. Millions of programmers would breathe a sigh of relief and maybe grow some hair back.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8590
  • FPC developer.
Re: Interfaces/Polymorphism
« Reply #21 on: December 06, 2019, 09:03:30 pm »
Actually that is wrong,  and old school opengl thinking. You can actually calculate the triangles from your own more highlevel definitions using the geometry shader. I do that all the time because I only show one in every <x>(*) images, so I write quite dense abstract info per image, and only one in every <x> is actually going to be displayed and the expansion is fairly free using the geometry shader.

p.s. x (*) typically being 5 or even more.
Oh, okay, I see. Somebody should tell the rest of the world, though!   ;D
[/quote]

here is an older unit test. Try it if you can run windows binaries somehow.

Quote
I just wish there was one graphics standard we programmers could use and leave it up to the OSes to implement it, either offloading it to the GPU, or gracefully falling back to native where necessary. Millions of programmers would breathe a sigh of relief and maybe grow some hair back.

I agree, but Apple creating yet another competing standard with metal, doesn't help things.

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #22 on: December 06, 2019, 09:44:05 pm »
I agree, but Apple creating yet another competing standard with metal, doesn't help things.
No, they should have got together with Intel, NVidia and AMD, et.al., and created one together. OpenGL is fine, but getting long in the tooth with however many current versions there are...

I tried reading up on Metal and how to draw a teapot. At about step 32 in setting up the canvas, my brain exploded.  %)

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #23 on: December 26, 2019, 11:29:37 pm »
Okay, dear Friends, it's crunch time!
First, the code:
Code: Pascal  [Select][+][-]
  1. {$mode objfpc}
  2.  
  3. type
  4.   THello = class
  5.     public
  6.       function WhoAmI: string; virtual;
  7.   end;
  8.  
  9.   TWorld = class(THello)
  10.     var
  11.       i: integer;
  12.     public
  13.       function WhoAmI: string; override;
  14.       function ANewMethod: string;
  15.   end;
  16.  
  17.   function THello.WhoAmI: string;
  18.     begin
  19.       Result := 'Hello'
  20.   end;
  21.  
  22.   function TWorld.WhoAmI: string;
  23.     begin
  24.       Result := ' World'
  25.   end;
  26.  
  27.   function TWorld.ANewMethod: string;
  28.     begin
  29.       Result := 'How are you?';
  30.   end;
  31.  
  32. var
  33.   a: THello;
  34.   b: TWorld;
  35.  
  36. begin
  37.   b := TWorld.Create;
  38.   WriteLn(b.WhoAmI);
  39.   WriteLn(b.ANewMethod);
  40.   b.i := 9;
  41.  
  42.   a := b;
  43.   WriteLn(a.WhoAmI);
  44.   WriteLn(a.ANewMethod); // <--- Fails compile!
  45.   a.i := 9;     // <--- This too!
  46. end.
  47.  
C++ happily can use a parent pointer to point to a child class and resolve its added methods and fields.  The VST framework deeply relies on this.

How can I get Pascal to do this? What am I missing?

simone

  • Sr. Member
  • ****
  • Posts: 351
Re: Interfaces/Polymorphism
« Reply #24 on: December 27, 2019, 12:21:52 am »
I'm not sure to understand your question. However you can compile the above code without errors using 'conditional typecasting':

Code: Pascal  [Select][+][-]
  1. ...
  2. begin
  3.   b := TWorld.Create;
  4.   WriteLn(b.WhoAmI);
  5.   WriteLn(b.ANewMethod);
  6.   b.i := 9;
  7.  
  8.   a := b;
  9.   WriteLn(a.WhoAmI);
  10.   WriteLn((a as TWorld).ANewMethod); // <---
  11.   (a as TWorld).i := 9;     // <---
  12. end.

Or using 'hard typecasting':
Code: Pascal  [Select][+][-]
  1. begin
  2.   b := TWorld.Create;
  3.   WriteLn(b.WhoAmI);
  4.   WriteLn(b.ANewMethod);
  5.   b.i due:= 9;
  6.  
  7.   a := b;
  8.   WriteLn(a.WhoAmI);
  9.   WriteLn(TWorld(a).ANewMethod); // <---
  10.   TWorld(a).i := 9;     // <---
  11. end.

I hope this can help you.
« Last Edit: December 27, 2019, 12:36:13 am by simone »
Microsoft Windows 10 64 bit - Lazarus 2.0.6

howardpc

  • Hero Member
  • *****
  • Posts: 3484
Re: Interfaces/Polymorphism
« Reply #25 on: December 27, 2019, 12:25:31 am »
It may be better to introduce a common ancestor class. Something like this:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. type
  6.  
  7.   TBase = Class
  8.   public
  9.     var
  10.       i: Integer;
  11.     function WhoAmI: String; virtual; abstract;
  12.   end;
  13.  
  14.   THello = class(TBase)
  15.   public
  16.     function WhoAmI: String; override;
  17.   end;
  18.  
  19.   TWorld = class(TBase)
  20.   public
  21.     function WhoAmI: String; override;
  22.     function ANewMethod: String;
  23.   end;
  24.  
  25.   function THello.WhoAmI: String;
  26.   begin
  27.     Result := 'Hello';
  28.   end;
  29.  
  30.   function TWorld.WhoAmI: String;
  31.   begin
  32.     Result := ' World';
  33.   end;
  34.  
  35.   function TWorld.ANewMethod: String;
  36.   begin
  37.     Result := 'How are you?';
  38.   end;
  39.  
  40. var
  41.   h: THello;
  42.   b: TBase;
  43. begin
  44.   h := THello.Create;
  45.   h.i := 9;
  46.   WriteLn(h.WhoAmI,' h.i=',h.i);
  47.  
  48.   b := h;
  49.   WriteLn(b.WhoAmI,' b.i=',b.i);
  50.   b.Free;
  51.  
  52.   b := TWorld.Create;
  53.   b.i := 99;
  54.   WriteLn((b as TWorld).WhoAmI,' b.i=',b.i);
  55.   WriteLn((b as TWorld).ANewMethod);
  56.   b.Free;
  57. end.

simone

  • Sr. Member
  • ****
  • Posts: 351
Re: Interfaces/Polymorphism
« Reply #26 on: December 27, 2019, 12:30:35 am »
My solution is 'quick and dirty'. The proposal of Howard is conceptually more correct.
« Last Edit: December 27, 2019, 12:32:55 am by simone »
Microsoft Windows 10 64 bit - Lazarus 2.0.6

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #27 on: December 27, 2019, 01:06:39 am »
I'm not sure to understand your question. However you can compile the above code without errors using 'conditional typecasting':

I hope this can help you.
It confirms that I had the right idea, but still the VST framework is passing around the wrong pointers. Overridden methods work fine, but additional fields and methods are not found whatsoever, even with casting.


I know it can be done, so I'll have to study the code some more.
« Last Edit: December 27, 2019, 01:13:23 am by syntonica »

syntonica

  • Full Member
  • ***
  • Posts: 120
Re: Interfaces/Polymorphism
« Reply #28 on: December 27, 2019, 01:12:40 am »
It may be better to introduce a common ancestor class. Something like this:
That might be the solution I'm looking for, except that I cannot inject variables into my base class.  :(

I'd do my class as a helper instead, but I have a couple dozen fields that I cannot include, but are required for the additional methods.

simone

  • Sr. Member
  • ****
  • Posts: 351
Re: Interfaces/Polymorphism
« Reply #29 on: December 27, 2019, 07:00:50 am »
It may be helpful to provide a portion of C ++ code to better illustrate your problem.  In this forum there are many who are fluent in this language too.
Microsoft Windows 10 64 bit - Lazarus 2.0.6

 

TinyPortal © 2005-2018