FPC clean room project

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: FPC clean room project

noreply
On Fri, January 6, 2017 8:59 am, Graeme Geldenhuys wrote:
> On 2017-01-06 15:49, Lars wrote:
>
>> What does this product allow?
>>
>
> CodeTyphon distributes the source code of Embarcadero's FireMonkey
> predecessor (previously known as VG-Scene or something), but rebranded as
> "Orca". Neither FireMonkey or its predecessor is/was open source.
>

LOL..

Okay but what's the point of it? to be able to compile firemonkey like
applications without buying delphi?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC clean room project

Graeme Geldenhuys-6
On 2017-01-06 16:14, Lars wrote:
> Okay but what's the point of it? to be able to compile firemonkey like
> applications without buying delphi?

Yes, you can build hardware accelerated GUI applications using that toolkit.


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: FPC clean room project

noreply
On Fri, January 6, 2017 9:21 am, Graeme Geldenhuys wrote:
> On 2017-01-06 16:14, Lars wrote:
>
>> Okay but what's the point of it? to be able to compile firemonkey like
>> applications without buying delphi?
>
> Yes, you can build hardware accelerated GUI applications using that
> toolkit.
>

Okay. hold on a second.  GUI applications, need hardware acceleration...
since when?  I guess this could be useful for animation based apps that
need to be zippy fast...?

AFAICT, gui applications, ever since windows 3.1 days on 33mhz computers,
were fast enough and needed no acceleration for basic things like buttons,
text, etc.

So does the hardware acceleration come in handy when you need to animate
something and make the gui app almost like a video? Scientific demos of
particles bouncing around?

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

Re: FPC clean room project

Michael Schnell
In reply to this post by Graeme Geldenhuys-6
On 06.01.2017 17:21, Graeme Geldenhuys wrote:
>
> you can build hardware accelerated GUI applications using that toolkit.
Not Really the point.

Can you use the toolkit plus fpc to compile and run Delphi Firemonkey
application source code (after a decent amount of tweaking) ?

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

Re: FPC clean room project

Tomas Hajny-2
In reply to this post by Mr Bee
Hello,

Could be potential further discussion about FireMonkey moved to fpc-other,
please? I don't think that it's still related to FPC...

Thank you

Tomas
(one of FPC mailing list moderators)


---------------------------- Original Message ----------------------------
Subject: Re: [fpc-pascal] FPC clean room project
From:    "Lars" <[hidden email]>
Date:    Fri, January 6, 2017 17:27
To:      "FPC-Pascal users discussions" <[hidden email]>


On Fri, January 6, 2017 9:21 am, Graeme Geldenhuys wrote:
> On 2017-01-06 16:14, Lars wrote:
>
>> Okay but what's the point of it? to be able to compile firemonkey like
>> applications without buying delphi?
>
> Yes, you can build hardware accelerated GUI applications using that
> toolkit.
>

Okay. hold on a second.  GUI applications, need hardware acceleration...
since when?  I guess this could be useful for animation based apps that
need to be zippy fast...?

AFAICT, gui applications, ever since windows 3.1 days on 33mhz computers,
were fast enough and needed no acceleration for basic things like buttons,
text, etc.

So does the hardware acceleration come in handy when you need to animate
something and make the gui app almost like a video? Scientific demos of
particles bouncing around?

What are the use cases for this?


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

Re: FPC clean room project

Sven Barth-2
In reply to this post by noreply
On 06.01.2017 16:44, Lars wrote:

> On Tue, January 3, 2017 6:10 pm, Snorkl e wrote:
>> They might with a change of ownership, who knows these days,  but the
>> fact they did use it in the past would not look good for any litigation
>> from some bottom feeder.
>
> The fact that they use FPC, means they likely reverse engineer FPC and
> apply their own hacks to their own compiler for multiple targets based on
> FPC engineering..
>
> i.e. they don't even need to reverse engineer FPC, they just have to dip
> their eyes into the source code... And woops, there comes the problem:
> Delphi is likely stealing from FPC too as their eyes have seen what cannot
> be undone... they've peered into the FPC source code guaranteed.. I bet.
>
> i.e. when they decide to target multiple platforms they have a nice demo
> to look into which already does it: fpc.
>
> Now I am not trying to insinuate anything here, but "it goes both ways"
>
> As Michael Van C. once said, why isn't Borland also practicing clean room?
> who is to say, since their development model is closed source, that their
> compiler has no violations in it, that rip from FPC?  With FPC the code is
> open so you can tell. With delphi, it's closed development, so you cannot
> peer into their compiler sources and check to see if there are violations.

Ehm... Delphi's compiler is written in C++, not Delphi as far as we
know. Also their NEXTGEN compiler is utilizing LLVM, something we won't
purely do.

Regards,
Sven

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

Re: FPC clean room project

Juha Manninen
In reply to this post by Michael Schnell
On Fri, Jan 6, 2017 at 6:41 PM, Michael Schnell <[hidden email]> wrote:
> Can you use the toolkit plus fpc to compile and run Delphi Firemonkey
> application source code (after a decent amount of tweaking) ?

No.

You should continue a Firemonkey discussion in fpc-other list, as
Tomas Hajny suggested.

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

Re: FPC clean room project

noreply
In reply to this post by Sven Barth-2
On Fri, January 6, 2017 12:51 pm, Sven Barth wrote:

> Ehm... Delphi's compiler is written in C++, not Delphi as far as we
> know. Also their NEXTGEN compiler is utilizing LLVM, something we won't
> purely do.


Yes the exe signature was c/c++

That does not forgive copyright just because different language is used..

Any fpc code can be easily converted to C code

In fact that hides copyright violations a bit as it masks them by
converting to a new language.

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

Re: FPC hardware accelerated GUI apps. Why?

noreply
In reply to this post by Tomas Hajny-2
On Fri, January 6, 2017 10:06 am, Tomas Hajny wrote:

> Hello,
>
>
> Could be potential further discussion about FireMonkey moved to
> fpc-other, please? I don't think that it's still related to FPC...
>
> Thank you
>
>
> Tomas
> (one of FPC mailing list moderators)
>

Fine, let me put it this way to keep it 100 percent on topic.

If FPC was able to create hardware accelerated GUI apps (nothing to do
with firemonkey... just in general if it was able to), is this useful?

How so?

What advantages do hardware accelerated GUI apps offer?

The way I see it is 99 percent of all GUI apps are fast enough back in
windows 3.1 days or the early days of X11 on bsd/linux.  There needs no
"acceleration".

However, on the other hand: animations, videos, scientific... maybe?

If FPC was able to target hardware accelerated GUI (or if it already does)
then what advantages would this offer people?  There must be some reason
for hardware accelerated GUI apps.

My buttons click fast enough without any accelerations on Windows 3.1...
on a 33mhz computer...

But maybe it's to do with flash style animations, video game like
interfaces for apps... 3D apps?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC hardware accelerated GUI apps. Why?

Marco van de Voort
In our previous episode, Lars said:
> > Could be potential further discussion about FireMonkey moved to
> > fpc-other, please? I don't think that it's still related to FPC...
> Fine, let me put it this way to keep it 100 percent on topic.
>
> If FPC was able to create hardware accelerated GUI apps (nothing to do
> with firemonkey... just in general if it was able to), is this useful?

Well, first, most GUI applications are already accelerated. So even if the
application has no explicit knowledge about it, it might use the GPU.

> What advantages do hardware accelerated GUI apps offer?

Aside from that, as an example, I implemented OpenGL support in my (work)
application simply to have smooth scrolling of large images without blocking
the main thread.  Low framerates (5-10, higher are rate limited), but large
images.  (2Mpx mono till 25mpx RGBA)

FM and some other seem to stress effects and control animations though, like
the trend in GUI was before it got win8-10 flat again. Probably that is
because it is easier to fixate in the API and requires less enduser ability
and effort.

> If FPC was able to target hardware accelerated GUI (or if it already does)
> then what advantages would this offer people?  There must be some reason
> for hardware accelerated GUI apps.

The main reason is to have a widget set that feeds the "real" gui system in
a compositive way. IOW if the screen needs to be redrawn, the OS or X
environment must be able to render the next scene without additional CPU
cycles.

This is important on the desktop (which is compositing since Windows Vista,
OS X since (afaik) 10.4), but even more so on mobile, since it simply means
that rendering the next image will run on the lower clocked, parallel GPU
rather than the higher clock, not so parallel CPU.

But that is less about actually doing stuff in the GPU but having a GPU
friendly model/abstraction. You can do old school rendering as long as you
pass it to the OS/XServer in a way it can composite it easily without
additional events, read: a modern API.  If the desktop then creates a new
arrangement of windows it doesn't have to call back into the application to
render the image again (like e.g. Windows GDI does).

Of course anybody designing any new widgetset will stress this fact, just
like anything nowadays should tick CSS and javascript bullets.

But all that requires actual OS/Xserver support.

> But maybe it's to do with flash style animations, video game like
> interfaces for apps... 3D apps?

I think the core desirable principle is to support compositing, as in no
application involvement to render the same image, but slightly stretched
(e.g. resizing a window) etc. You can of course extend this slightly to
animation. Instead of the desktop calling the application to render every
new sequence in the application, you pass the animations frames at once, and
leave it to the desktop to render it optimally.

This leads too general more responsive GUI, with lower CPU usage (mobile
again), even if the elements are reletively hires and complex.

Of course the marketeers want to sell you some hyped up vision of it, but
the core concept is ok.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: FPC clean room project

Mark Morgan Lloyd-5
In reply to this post by noreply
On 07/01/17 19:30, Lars wrote:

> On Fri, January 6, 2017 12:51 pm, Sven Barth wrote:
>
>> Ehm... Delphi's compiler is written in C++, not Delphi as far as we
>> know. Also their NEXTGEN compiler is utilizing LLVM, something we won't
>> purely do.
>
>
> Yes the exe signature was c/c++
>
> That does not forgive copyright just because different language is used..
>
> Any fpc code can be easily converted to C code
>
> In fact that hides copyright violations a bit as it masks them by
> converting to a new language.

I don't think that copyright would survive translation. A patent of the
algorithms would, but that is opening a whole new can of worms.

Whoever owns Delphi these days might be able to claim a "look and feel"
violation, but ultimately Delphi used ideas which had previously been
demonstrated viable by MS VB, even if Borland's implementation was
vastly improved.

So I don't think we need to give anonymous trolls a platform.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12