gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Painter Fuzzy Node in github


From: Ivan Vučica
Subject: Re: Painter Fuzzy Node in github
Date: Tue, 16 Dec 2014 15:48:22 +0000

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

See my previous answer in the mail "patch for start on Opal Work",
I will put it on the wiki at http://wiki.gnustep.org/index.php/Fuzzy

I will write some documentation about what I am trying to do over there. I'll tell you when it's ready. The main purpose is putting some machine learning in a NextStep/GNUstep system which has enough idle cycles already.

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.'
 
 
- How, if at all, it fits in with GNUstep.

It alleviates the GNUstep system with less simpler screen updating for example.

"Less simpler" is not a positive thing. :-)

Assuming you meant "...with simpler screen updates", I'll ask in what way. Do you mean "with less redraws"?

My understanding is that you plan to implement this as a graph of nodes, each node is either a painting method or a fuzzy logic function. If all fuzzy logic in the chain evaluates to a "yes, please paint", then the painting is indeed executed.

Is my interpretation that this graph is actually a tree correct?

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.

As a seperate library it can even be used for games built with GS :-)

You don't seem to be implementing it as a separate library?
 
I hope I answer your questions this way.

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

If you are looking for something whose rendering is affected by a tree, I think Core Animation would be a way better thing to look at. "How is this CALayer rendered? Let's look at its parent layers." You could then stuff in quasi-layers that would evaluate fuzzy logic. How you'd go about that is left as an exercise.

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'.
--
Ivan Vučica
address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]