Re: Painter Fuzzy Node in github

[Ivan Vučica]

I'll be far more direct in this email, and I expect my involvement in this thread to end with this.

I may comment again if you have a significant proof of why your approach is good. I don't think anyone's opinion will be swayed until you have a small demo UI library written in clean, idiomatic Objective-C demonstrating benefits of your approaches. At that point we can discuss /whether/ to /consider/ adopting the approach into gnustep-gui and gnustep-back.

On Thu, Dec 18, 2014 at 12:29 PM, Johan Ceuppens <address@hidden> wrote:

2014-12-18 12:42 GMT+01:00 Ivan Vučica <address@hidden>:

I think I get what you want.

You want to predict which areas of the screen might require an update in near future, and pre-render the updated graphics. Then, when the time comes, you want to quickly blit the prerendered update on the screen.

I do not prerender, I predict :-)

If you weren't thinking of predictively prerendering things and caching them for later rendering, then this is actively working against user's experience. Humans have vision that is far greater than the screen size, meaning they perceive more than the area around cursor. Especially so if they are not actively following the cursor around the screen (which they aren't a lot of the time).

You can't just guess what to render based on where the cursor is; you should update the screen as soon as possible in response to events. It doesn't matter if it's a timer event or a mouse event; if you don't redraw immediately in response to e.g. timer event, you're making redraws far harder to predict for the developer of the app, which is bad for everyone involved: the user and the developer.

 

(If I may be blunt on AI techniques) I need to develop the fuzzy math functions for a renderer together with fuzzy rulesets or networks.

Sorry, but that sentence doesn't carry useful information.

The thing is that you indeed render the screen partly i.e. rootwindow from GS with all apps, components, Widowmaker and so on.

Yes -- they already get rendered partly: when X11 requests that due to loss of content inside an X11 window, or when portion of the screen needs to render in response to an event.

 

The idle time for idling the renderer gets used to reason around your GS system.

I'll be very blunt: what does this even mean?

 

That's it apart from GS games such as GMines which can have my system built-in (I told you it was portable objc no deps) so that line, rectangle or pixel drawing gets reasoned around together with e.g. in-game AI.

There is no point in reasoning about it intelligently. If I receive an event that a mouse has entered my widget and I respond by issuing setNeedsDisplay, I expect the redraw to happen as soon as possible -- which is currently 'within the same pass of the event loop', possibly even 'immediately'.

I don't want the system to question me. I /know/ this needs to happen immediately. And if I issue a command to draw a line, I expect it to be carried out at the time when I issued it (within the relevant drawRect), not at some unspecified time in the future. There are no benefits to delaying it.

 

I doubt GNUstep will have buttons animated with a glow animation before it can render things as layers on GPU, and when it does, advantages you'd get from prerendering this probably be lost. 

The rule in prolog would be "paint([layer1,layer2,layer3])" with e.g. idle 100 mseconds in between. Note that you can drive the idle and painting mechanism so that you even can render 12 frames (for human eyes) and negate all other dumb rendering, caching compositing cannot better that part of the system.

Again, bluntly: What does this even mean?

 

A cool thing about Cocoa and GNUstep is that, as complex as the rendering process already is, it is still understandable and debuggable. Adding unpredictable update triggers may make debugging harder.

It's better interrupt handling yes and it can be done in several ways,

How are interrupts involved here? You've mentioned them several times.

I don't care about interrupts. This isn't low level programming. If the API such as X11 delivers an event, I usually don't care how it's generated; I don't care if the events are generated by hardware interrupts, which are translated into input device events by the kernel, which are translated into X11 events by the X server, which are then delivered to me. Same for timers.

There isn't really a way to improve interrupt handling for me than 'convert it into events with as low latency and possible and let me handle them as soon as realistically possible after they get delivered into AppKit'.

There is no reason for me to want to delay blitting updates on the screen except caching it in a controlled manner.

 

libsigc++ comes to mind but again my thing is portable, no deps. This is why I need good interfaces for the GSFuzzy library.

"libsigc++ implements a typesafe callback system for standard C++" -- how is this even related to what you're trying to accomplish?

OPENSTEP-derived systems have wonderful options for specifying callbacks, including as target+selector+argument tuples invoked with [target performSelector:sel withObject:arg], often wrapped into an NSInvocation if you need more than one argument, etc.

Your code, by the way, reveals that you are unaware of how handy target+selector approach is. I would highly advise you to practice writing real-life applications with GNUstep (with a goal explicitly being to learn idiomatic approaches to writing Objective-C), to read Apple's and other people's tutorials, and to read loads and loads of existing Objective-C code to get a feeling for how things are done with *STEP systems. Please do so before attempting to patch GNUstep.

Objective-C allows for very dynamic systems. Your code does not make use even of the fact that you can [target performSelector:NSSelectorFromString(@"hello:") withObject:world];, much less demonstrate what your approach will be or how it is better than what almost every other UI library in existence does.

 

 Either way, I can put it in as a game library developed with and for GS and GS games.

If you do so and it proves useful, we can reexamine your approach.

Please do not reuse the name Opal for this unrelated library.

--

Ivan Vučica

address@hidden