Re: Painter Fuzzy Node in github

[Johan Ceuppens]

Hi,

I will try to understand better before posting more but here's an essay :

2014-12-16 17:58 GMT+01:00 Ivan Vučica <address@hidden>:

I will assume that you meant these two emails to go to the list as well. I have trimmed out the parts I don't have a response to.

On Tue, Dec 16, 2014 at 4:18 PM, Johan Ceuppens <address@hidden> wrote:

Thank you for the text. I'm not sure it belongs on the GNUstep wiki, at least not without a large banner saying: 'This is a proposal for an approach that is not yet part of GNUstep.'

I put that on the page right away with the fact that there is source code for it.

Thanks!

It's updated and for further reference is at http://wiki.gnustep.org/index.php/Fuzzy there is also a link at http://wiki.gnustep.org/index.php/Gnustep-fuzzy (I could not trim the wiki's capital G.)

 

I don't really see a use for this in non-games. I don't think it should live in core GNUstep. It complicates the basic widget painting more than it already is. And I assure you that it is already tricky to get a backend working right; one of the reasons is that GNUstep's painting is already quite efficient.

I understand and won't interfere as I am a gnustep newbie (and my objc is about 10000+ and that's it) but distributed and parallell processing are at our door and make for heavy processing on large displays

Sure -- and GPUs are really good at drawing things in parallel.

OK, so I am also writing for games again. That's good, I wrote quite a few of them actually :-)

This is where Core Animation kicks in.

 

for example which is bettered by AI.

How?

Perhaps the problem that I'm having is:
 

- What real-life product do you have in mind where you'd make use of 'distributed' fuzzy logic 'networks' for painting?

Things which render or use X11 event functionality.

 

- Why /exactly/ do you assume it would be better than existing approaches to rendering?

Generally, a system becomes smarter with AI. This goes way back though.

 

- What exactly do you presume will benefit from AI in the rendering world? Why exactly?

Basically it's called better interrupt handling.

 

- Will this make it faster and easier to write GNUstep applications? How?

For GNUstep games and smart rendering e.g. with a mouse node this is faster. "3D rendering always happens at the middle of the viewport" by which I mean where you click your mouse is where a 3D walk algorithm must update and it proliferates to the rest of the screen. By aiming though e.g. with a first person shooter the update gets smarter. This is grossly how a game could benefit.

 

- Will this make GNUstep applications faster? How? By how much?

Machines are way too fast for a simple renderer. Again we come into a 3D rendered window system which is not what GS will become I guess.

 

- Will this make GNUstep's rendering path easier or harder to understand? If harder, is this worth the maintenance burden?

My code is easy to understand as I program for people not for stacking order or pattern-wise so maintenance should be OK. Also remember this is GNU software and the rendering path will be as simple as the API, see previous mails or the Fuzzy wiki page for more information.

 

Summary: What exactly are you planning to write with these new APIs?

Anything AI based so games and idle time tasks come to mind e.g. SETI :-)

 

Also do not forget you idle a lot which gives gnustep time to do something else such as spider or whatnot.

But, idling is good -- power use of the system goes down, not to mention the user can use the resources in different apps.

 

Right, I want to add that applications can be multiple windowed such as standard the gimp.

 

Before you proceed with this, I would suggest that you examine the entire stack of graphics technologies available under systems evolved based on OPENSTEP.

Does anyone have some pointers for this ? This would be from GL to EGL and the pheared DirectX. This all comes down to accelerating with screen drivers nothing in the X11 user space, relating to DirectX in this case.

The stack that I was thinking of is, on Apple platforms, approximately:
- OpenGL (where OpenGL ES is a simplification, and Direct3D being the remaining non-deprecated analogue within world of DirectX)

- Core Animation + Core Graphics

- AppKit / UIKit

AppKit and UIKit draw content into Core Animations' CALayers, and Core Animation's renderer actually puts it on the screen. 

GNUstep has only AppKit, and currently blits things onto the screen without CA, CG or OpenGL. This is done by a lower level library such as Cairo.

- Cairo (or Libart, or Xlib, or Opal which happens to use Cairo...)

- gnustep-back

- AppKit / gnustep-gui

 

I understand though that OPENSTEP is the way to go for GS.

OPENSTEP is a specification from mid-1990s, and not 'the way to go'.

Please read on history of NeXT, NEXTSTEP and OPENSTEP.

Here's where I need quite some time as I am not familiar with apple's objc or GS. This is why I probably start better at a library on the side e.g. for GS game building which I need to integrate later on. I hope nobody minds putting the "this is part of GNUstep" on it ?

 

On Tue, Dec 16, 2014 at 4:50 PM, Johan Ceuppens <address@hidden> wrote:

Of course, one would need to clean up GNUstep's implementation of CA, but it seems like a far better fit for 'let's use a tree to decide whether something is drawn or not'.

Could you explain where and what CA is so I can maybe integrate my code in a better way ?

For information about what Core Animation is, I'd really suggest reading about it in Apple's documentation.

GNUstep's implementation of the API lives in:

  http://www.google.com/search?q=CALayer+site:svn.gna.org

That is, the library is called 'quartzcore' for historical reasons.

  http://svn.gna.org/svn/gnustep/libs/quartzcore/trunk

OK, I'll look into that and will send some more mail about this later on.

`Enry