29-Mar-2024 08:03 GMT.
UNDER CONSTRUCTION
Anonymous, there are 59 items in your selection [1 - 50] [51 - 59]
[News] New version of Feelin (040718) & Web siteANN.lu
Posted on 21-Jul-2004 04:39 GMT by Gofromiel59 comments
View flat
View list
Feelin is a new object-oriented system (OOS) for the AmigaOS. It provides two things: a small, fast and powerful core shared library, offering everything needed to create a strong object-oriented environnement; and an extensible system to create and maintain graphical user interfaces.

I created Feelin, because I was fed up with others GUI toolkits available on AmigaOS. You may say "have you ever heard about MUI ?". Well, yes :-) But, although MUI is a very attractive choice, it severely lacks of modern features and protection. MUI is not an object-oriented system on its own. Built on BOOPSI, it suffers from its limitations.

Give it a try ! Visit Feelin's web site for further information...

New version of Feelin (040718) & Web site : Comment 1 of 59ANN.lu
Posted by koan on 21-Jul-2004 05:16 GMT
I think this looks very promising; I don't know a lot about Amiga GUI programming so I can't comment on the implementation.

My suggestion is that you make more demos and post more screenshots; I'd be especially interested in seeing a MUI based application rewritten to use this system.

Add optional antialiased font support (maybe link to TTEngine ?) and gradients and you can't wrong, although your benchmarks might suffer!

koan
New version of Feelin (040718) & Web site : Comment 2 of 59ANN.lu
Posted by Peter Gordon on 21-Jul-2004 06:19 GMT
Good work and everything, but do you honestly think the Amiga needs another GUI toolkit? I mean, isn't Intuition direct, Gadtools, ReAction/ClassAct, MUI, BGui, Triton, GTLayout and the myriad of others enough?
New version of Feelin (040718) & Web site : Comment 3 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 06:25 GMT
This certainly looks promising! GREAT job! Thx ;)
New version of Feelin (040718) & Web site : Comment 4 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 06:27 GMT
In reply to Comment 3 (Amon_Re):
I don't see it as a problem really, choice is good, aslong as all the toolkits are capable of maintaining a consistant look.
New version of Feelin (040718) & Web site : Comment 5 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 06:32 GMT
A little suggestion, mention the licence terms on your website, because at first glance i couldn't find it ;)
New version of Feelin (040718) & Web site : Comment 6 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 06:39 GMT
The main library is written directly in 68k assembler. Anyone dreaming about native MorphOS or AmigaOS 4 version? Emulated GUI engine - it does not sound reasonably.
New version of Feelin (040718) & Web site : Comment 7 of 59ANN.lu
Posted by Don Cox on 21-Jul-2004 08:35 GMT
In reply to Comment 6 (Grzegorz Kraszewski):
"Emulated GUI engine - it does not sound reasonably."

That depends on how fast the hardware and the JIT emulation are. The result could be ten times as fast as native code running on a 68060, which is presumably what the author is coding for.
New version of Feelin (040718) & Web site : Comment 8 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 09:02 GMT
In reply to Comment 7 (Don Cox):
Emulated code will never be as fast as native one, regardless of JIT efficiency.
New version of Feelin (040718) & Web site : Comment 9 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 09:08 GMT
In reply to Comment 8 (Grzegorz Kraszewski):
> Emulated code will never be as fast as native one, regardless of JIT efficiency.

Prove it, I dare you! ;-)

There's plenty of examples, and theoretical explanations, for why a JIT can produce faster code than a native compiler.
New version of Feelin (040718) & Web site : Comment 10 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 09:50 GMT
In reply to Comment 9 (Fabio Alemagna):
Doublecheck if those examples are about 680x0 JIT-emulated on PowerPC. And then show me an Amiga application having 68k and PPC version and running faster on emulation than native (of course excluding PowerUP/WarpOS for context-switch reasons).
New version of Feelin (040718) & Web site : Comment 11 of 59ANN.lu
Posted by Anonymous on 21-Jul-2004 09:52 GMT
In reply to Comment 9 (Fabio Alemagna):
> There's plenty of examples, and theoretical explanations, for why a JIT can produce faster code than a native compiler.

There is also plenty of examples and theoretical explanations for why a JIT usually produces slower code than a native compiler ;) But here, I'd agree. At some point, with a certain amount of CPU power, the difference in speed just doesn't matter, because all user-driven applications have a built-in speed limit: the user. Drawing gadgets is so simple, even managed code should be able to do that instantly, taking into account that all actual rendering is done natively by the OS.
New version of Feelin (040718) & Web site : Comment 12 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 09:52 GMT
In reply to Comment 10 (Grzegorz Kraszewski):
P.S. Switching from native code to emulated one (as when PPC native app will use Feelin) also contributes to the slowdown. Of course this context-switch is not as painfull as PUP/WOS one, but the overhead exists.
New version of Feelin (040718) & Web site : Comment 13 of 59ANN.lu
Posted by Anonymous on 21-Jul-2004 09:59 GMT
In reply to Comment 10 (Grzegorz Kraszewski):
> then show me an Amiga application having 68k and PPC version and running faster on emulation than native

That may be difficult but it is easy to find applications that run at the same speed in both versions because they are tied to timing parameters beyond their control. That can be timers, the vertical blanking interrupt, the intended frame rate of a video, the keyboard repeat rate, the maximum speed of the mouse etc. As long as managed code can keep up the the demand on that side, native code doesn't add to the speed. That is why Word and similar applications scale well for a while (going from 100 MHz to 1000 MHz or so) but after that just won't feel much faster: the additional speed is wasted on them in most situation, the CPU sits idle.
New version of Feelin (040718) & Web site : Comment 14 of 59ANN.lu
Posted by itix on 21-Jul-2004 10:08 GMT
In reply to Comment 10 (Grzegorz Kraszewski):
JIT can eliminate redundant instructions in run time (compile 68k to PPC + optimize). If translation phase is not accounted then JIT code can be faster than native PPC code.
New version of Feelin (040718) & Web site : Comment 15 of 59ANN.lu
Posted by itix on 21-Jul-2004 10:19 GMT
About day's topic: I think this is coming too late. This could have been cool 5 years ago but now, in 2004, we have PPC native MUI and Reaction (OS4). We should move towards consistent GUI system. One toolkit, uniform look. Few cases why I think this is coming late: "Because they have an embended semaphore, Feelin's pools can easily be shared between applications." Semaphore protected memory pools are supported by MorphOS. "Finaly, if a memory allocation fails or if you try to dispose an unknown memory block, a message is logged on the default debug ouput of Feelin." Maybe nice in AmigaOS 3, but MorphOS got debug options to find this out. "And you know what ? Even with all theses lovely features, Feelin's memory management system is faster than EXEC's one, 2 to 4 times (tested under WinUAE and my beloved A1200)." I'm not so sure if this is significant. ExecPPC (MorphOS) and ExecSG (AmigaOS4) are very different from AmigaOS 3 Exec.
New version of Feelin (040718) & Web site : Comment 16 of 59ANN.lu
Posted by itix on 21-Jul-2004 10:23 GMT
In reply to Comment 15 (itix):
But doesn't look bad:http://perso.numericable.fr/~olaviale/feelin/images/screens/01_hi.png
New version of Feelin (040718) & Web site : Comment 17 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 10:33 GMT
In reply to Comment 13 (Anonymous):
GUI engine is not timer driven.
New version of Feelin (040718) & Web site : Comment 18 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 10:36 GMT
In reply to Comment 14 (itix):
You assume a native compiler does not remove redundant instructions during optimization pass? Also not taking translation time in JIT emulator is wrong for GUI engine, as GUI code does not run in one well defined tight loop, it is called irregularly depending on user activity and has a lot of branches.
New version of Feelin (040718) & Web site : Comment 19 of 59ANN.lu
Posted by Anonymous on 21-Jul-2004 10:52 GMT
In reply to Comment 17 (Grzegorz Kraszewski):
> GUI engine is not timer driven

I don't mean timers as in 'hardware timers' but in the sense of parameters with inherent timing/speed. A GUI toolkit's main constraint is the user, who interacts with the toolkit through mouse and keyboard. All - mouse, keyboard, human - have a maximum speed. There are also timer-driven elements in a toolkit, like the scroll rate (intuiticks). The point is that a GUI toolkit and in fact most applications are not applications like a compiler that "just run" and translate whatever CPU power and code quality is available into more speed, but event-driven: after a break-even point, more CPU power or more native code doesn't make the program faster. Btw, it's not so difficult to write a fast toolkit in managed, non-native code, wiht a decent JIT. I'm not using Jave and .net but arent's those toolkits non-native, too, at least to a degree?
New version of Feelin (040718) & Web site : Comment 20 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 11:23 GMT
In reply to Comment 11 (Anonymous):
> There is also plenty of examples and theoretical explanations for why a JIT
> usually produces slower code than a native compiler ;)

That's irrelevant. The claim was that a JIT compiler can never produce faster code than a native compiler. Such claim is bogus, and all I need to do to prove it is to point out implementations and explanations for why this is so.
New version of Feelin (040718) & Web site : Comment 21 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 11:27 GMT
In reply to Comment 10 (Grzegorz Kraszewski):
> Doublecheck if those examples are about 680x0 JIT-emulated on PowerPC.

You didn't state such a constraint before, and I replied to such an unconstrainted statement.

Even then, MOS' JIT can, at some places, produce code that runs faster than equivalent C code compiled with the available native compiler.

There are some optimizations that can only be done at runtime, and that's why a well-written JIT compiler can do better than a static compiler.
New version of Feelin (040718) & Web site : Comment 22 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 13:13 GMT
In reply to Comment 18 (Grzegorz Kraszewski):
A JIT emulator (a good one) would profile the code as it runs to optimise it, you can do that with normal compilers too, but according to research done by, amongst others, the JIT can and will often rival & surpass the standard compiled native version.
New version of Feelin (040718) & Web site : Comment 23 of 59ANN.lu
Posted by Crumb // AAT on 21-Jul-2004 14:49 GMT
In reply to Comment 21 (Fabio Alemagna):
"Even then, MOS' JIT can, at some places, produce code that runs faster than equivalent C code compiled with the available native compiler."

Can you give us any real world example?
New version of Feelin (040718) & Web site : Comment 24 of 59ANN.lu
Posted by Don Cox on 21-Jul-2004 15:52 GMT
In reply to Comment 8 (Grzegorz Kraszewski):
"Emulated code will never be as fast as native one, regardless of JIT efficiency."

I would expect around half speed, but when some code has been written to run at a good speed on 68k, it will run very fast on a modern CPU with JIT.
New version of Feelin (040718) & Web site : Comment 25 of 59ANN.lu
Posted by Don Cox on 21-Jul-2004 15:55 GMT
In reply to Comment 15 (itix):
"We should move towards consistent GUI system. One toolkit, uniform look."

Why do you want a uniform look? I prefer each program to have a look that suits its purpose.

I would not want a word processor to look like a 3D animation program, or a spreadsheet to look like an animation player.
New version of Feelin (040718) & Web site : Comment 26 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 15:58 GMT
In reply to Comment 23 (Crumb // AAT):
> Can you give us any real world example?

Define "real world", please.
New version of Feelin (040718) & Web site : Comment 27 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 15:59 GMT
In reply to Comment 25 (Don Cox):
> Why do you want a uniform look? I prefer each program to have a look that
> suits its purpose.
>
> I would not want a word processor to look like a 3D animation program, or a
> spreadsheet to look like an animation player.

He's of course talking about the shape of the common gadgets, not about different gadgets designed for their own special purposes. Consistency is that, and also the semantics of the various gadgets which should be the same across all applications.
New version of Feelin (040718) & Web site : Comment 28 of 59ANN.lu
Posted by Christoph Gutjahr on 21-Jul-2004 16:17 GMT
In reply to Comment 25 (Don Cox):
>> Why do you want a uniform look? I prefer each program to have a look that
>> suits its purpose.

>> I would not want a word processor to look like a 3D animation program, or a
>> spreadsheet to look like an animation player.

Here's a simple example: Imagine a plain standard "Yes/No?" requester. Depending on the GUI toolkit used to display that requester, it opens under the mousepointer, in the top left corner of the screen, in the center of the window or in the center of the screen. Some of them pop the screen to the front, some don't. Dpending on the GUI toolkit used, they can be answered using a subset (different subset for each GUI toolkit of course) of these options:

- mouse only
- LAmiga-V / LAmiga-B
- 'Y' / 'N'
- 'Enter' for 'Yes'
- Control+Enter for 'Yes'
- Enter / Escape
- F1 / F2
- TAB to highlight option, enter to select

The myriad of keyboard shortcuts available for texfields or string gadgets is even worse.
New version of Feelin (040718) & Web site : Comment 29 of 59ANN.lu
Posted by Agima on 21-Jul-2004 16:18 GMT
In reply to Comment 27 (Fabio Alemagna):
>>He's of course talking about the shape of the common gadgets,
>>not about different gadgets designed for their own special
>>purposes. Consistency is that, and also the semantics of
>>the various gadgets which should be the same across all applications.


That's what makes Windows so damn bland. Every program looks like your using Internet Explorer.

Programs in a lot of cases should have there own look. ie. Something like DigiBooster Pro. It has it's own very distinct GUI that is quite a bit different then Workbench or IBrowse. Consistancy is good, but diversity is good as well.
New version of Feelin (040718) & Web site : Comment 30 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 17:04 GMT
In reply to Comment 22 (Amon_Re):
So we should throw out our PPC compilers and compile for 68k because it runs faster ;-) ? MOS kernel should be compiled for 68k too? I have one good example showing JIT emulation is not so good - dnetc client. It is an application running the same loop again and again, so JIT compiler can do its best. But emulated dnetc is significantly slower than native one (I'm comparing to native client without AltiVec of course). So please stop tell me this "JIT can be faster"...
New version of Feelin (040718) & Web site : Comment 31 of 59ANN.lu
Posted by Grzegorz Kraszewski on 21-Jul-2004 17:10 GMT
In reply to Comment 21 (Fabio Alemagna):
You didn't state such a constraint before, and I replied to such an unconstrainted statement.

You seem to forgot about the topic of discussion. It is obvious we are talking on software compiled for 68k and this 68k is emulated on PowerPC. So your talk about constrains is well... discussion just for discussion itself.
New version of Feelin (040718) & Web site : Comment 32 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 17:53 GMT
In reply to Comment 30 (Grzegorz Kraszewski):
Look, i know nothing about the MOS jit engine, i was referencing to a motorola study, there are afew intresting topics about this at arstechnica
New version of Feelin (040718) & Web site : Comment 33 of 59ANN.lu
Posted by Fabio Alemagna on 21-Jul-2004 17:56 GMT
In reply to Comment 31 (Grzegorz Kraszewski):
> You seem to forgot about the topic of discussion. It is obvious we are talking
> on software compiled for 68k and this 68k is emulated on PowerPC.

Sorry, but yours was a general claim, how am I supposed to know you don't think your claim applies generally? It might very well be that someone thinks that a JIT compiler will never produce better code than any native compiler, it's quite a possible and plausible stance.

Besides, there's nothing that says that a JIT compiler for 68k code to PPC code is somewhat "special" and cannot produce better code than a native compiler.

> So your talk about constrains is well... discussion just for discussion
> itself.

It's a general discussion aimed at providing information on the basis of which one can draw the conclusion that, generally speaking, any JIT compiler can be made in such a way so to produce code that runs better than code compiled natively. There are theoretical reasons for this, and practical examples.

A 68k->PPC JIT compiler isn't any different from the rest, and doesn't deserve a special treatment. The fact that the JIT compilers currently available within the Amiga market are not up to that task yet, or always, doesn't mean thet cannot be made better.
New version of Feelin (040718) & Web site : Comment 34 of 59ANN.lu
Posted by Elwood on 21-Jul-2004 19:09 GMT
Hey Olivier, you are still developing it then :-)
Do you want to work on OS4 ? Some coding skills are required to work on Reaction...
New version of Feelin (040718) & Web site : Comment 35 of 59ANN.lu
Posted by Anonymous on 21-Jul-2004 19:44 GMT
In reply to Comment 24 (Don Cox):
> I would expect around half speed, but when some code has been written to run at a good speed on 68k, it will run very fast on a modern CPU with JIT

If the OS is native, like MorphOS, it depends on the amount of OS calls. If you profile a program, you will find that it is not unusual that programs spend most of their time in (native) OS functions, especially in rendering-related functions. Such programs easily reach near 100% of native versions. Btw, the MorphOS JIT is really very very fast :)
New version of Feelin (040718) & Web site : Comment 36 of 59ANN.lu
Posted by Anonymous on 21-Jul-2004 19:46 GMT
In reply to Comment 30 (Grzegorz Kraszewski):
> So we should throw out our PPC compilers and compile for 68k because it runs faster ;-)?

No, but you should make a 68k version because speed is, for most programs and a decent JIT, a dumb argument.
New version of Feelin (040718) & Web site : Comment 37 of 59ANN.lu
Posted by Amon_Re on 21-Jul-2004 20:25 GMT
In reply to Comment 35 (Anonymous):
Don't forget that some JIT engines profile code while it runs, further optimising it, so yes, you can achieve native speed or better with JIT technology, it depends on the complexity of the JIT.
New version of Feelin (040718) & Web site : Comment 38 of 59ANN.lu
Posted by itix on 21-Jul-2004 23:18 GMT
In reply to Comment 29 (Agima):
"Programs in a lot of cases should have there own look. ie. Something like DigiBooster Pro. It has it's own very distinct GUI that is quite a bit different then Workbench or IBrowse. Consistancy is good, but diversity is good as well." No but I hate it when in every 2nd program mouse wheel scrolls lister and in every 2nd program it doesnt. Or you have ten different toolbars every working differently. Some support floating toolbars, others have flat buttons, some other programs dont have toolbar at all... Diversity is good in small quantities, i.e. in ANR ;) Now let's wait when the first GUI toolkit appears to SDL... :P
New version of Feelin (040718) & Web site : Comment 39 of 59ANN.lu
Posted by Jon on 22-Jul-2004 06:25 GMT
In reply to Comment 38 (itix):
Are you, by any change, planning to do one?-)
New version of Feelin (040718) & Web site : Comment 40 of 59ANN.lu
Posted by Grzegorz Kraszewski on 22-Jul-2004 07:43 GMT
In reply to Comment 36 (Anonymous):
Software I'm writing is MorphOS only anyway, so there is no need for 68k version.
New version of Feelin (040718) & Web site : Comment 41 of 59ANN.lu
Posted by Amon_Re on 22-Jul-2004 07:45 GMT
In reply to Comment 40 (Grzegorz Kraszewski):
May i ask what you are writing?
New version of Feelin (040718) & Web site : Comment 42 of 59ANN.lu
Posted by Fabio Alemagna on 22-Jul-2004 08:11 GMT
In reply to Comment 38 (itix):
> Now let's wait when the first GUI toolkit appears to SDL... :P

Uh, there are lots already :-)

http://www.free-soft.org/guitool/
http://freshmeat.net/search/?q=SDL+GUI§ion=projects
New version of Feelin (040718) & Web site : Comment 43 of 59ANN.lu
Posted by Anonymous on 22-Jul-2004 08:26 GMT
In reply to Comment 40 (Grzegorz Kraszewski):
> Software I'm writing is MorphOS only anyway, so there is no need for 68k version

Software that is MorphOS only or AmigaOS4 only is questionable, as if any of those had killer features beyond the OS3/MUI/AHI/CGFX/... API that would warrant exclusive development for one niche (only a few things excluded, like a themes manager for MorphOS etc., that must be OS-specific). For giving up compatibility in favour of MorphOS or OS4, you get pretty little in return, in terms of kliller features, but loose 75% of potential users. To loose so many users, the OS had to be the mother of all operating systems, if you ask me.
New version of Feelin (040718) & Web site : Comment 44 of 59ANN.lu
Posted by Grzegorz Kraszewski on 22-Jul-2004 08:48 GMT
In reply to Comment 43 (Anonymous):
You are right, but I'm coding just for fun, so don't care.
New version of Feelin (040718) & Web site : Comment 45 of 59ANN.lu
Posted by Grzegorz Kraszewski on 22-Jul-2004 08:49 GMT
In reply to Comment 41 (Amon_Re):
Some kind of datatype.
New version of Feelin (040718) & Web site : Comment 46 of 59ANN.lu
Posted by Grzegorz Kraszewski on 22-Jul-2004 08:51 GMT
In reply to Comment 43 (Anonymous):
Forgot to mention I'm a damned blue troll, so programming something not running on OS4 is entertaining.
New version of Feelin (040718) & Web site : Comment 47 of 59ANN.lu
Posted by Amon_Re on 22-Jul-2004 09:29 GMT
In reply to Comment 45 (Grzegorz Kraszewski):
Well, the best of luck with it, i'd say :P
New version of Feelin (040718) & Web site : Comment 48 of 59ANN.lu
Posted by Anonymous on 22-Jul-2004 09:56 GMT
In reply to Comment 8 (Grzegorz Kraszewski):
He said:

"The result could be ten times as fast as native code running on a 68060"

Sure even emulated code can be MUCH faster than native code on a 68060. G3 and G4 is so much faster than 68060 that emulated code flies when compared speed on 68060.
New version of Feelin (040718) & Web site : Comment 49 of 59ANN.lu
Posted by Anonymous on 22-Jul-2004 10:03 GMT
In reply to Comment 46 (Grzegorz Kraszewski):
That's wery stupid attitude. Maybe you are too childish to know what co-operation means.
New version of Feelin (040718) & Web site : Comment 50 of 59ANN.lu
Posted by Anonymous on 22-Jul-2004 10:14 GMT
From the feelin website:

"EXEC's FreePooled() requires the memory pool pointer in which the chunk have been allocated, a pointer to this chunk and its size, feelin only requires the chunk pointer."

That's good idea. But it's not any problem to implement your own AllocVecPooled() and FreeVecPooled(). I always use those in my AmigaOS3.x code which needs pools.
Anonymous, there are 59 items in your selection [1 - 50] [51 - 59]
Back to Top