There are still a few differences with what I am writing : 2014-12-18 12:42 GMT+01:00 Ivan Vučica <i...@vucica.net>: > > 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 I may be blunt on AI techniques) I need to develop the fuzzy math functions for a renderer together with fuzzy rulesets or networks.
The thing is that you indeed render the screen partly i.e. rootwindow from GS with all apps, components, Widowmaker and so on. The idle time for idling the renderer gets used to reason around your GS system. 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. > Now, here are the issues. > > GNUstep currently doesn't have animated widgets, especially not > dynamically rendered ones, so you'll have a very, very hard time finding a > proper use case for this. And you won't have noticeable speeds-up from > caching even that, either; GPUs can composite things faster than you can > cache them. > > I concur. > 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. > 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, libsigc++ comes to mind but again my thing is portable, no deps. This is why I need good interfaces for the GSFuzzy library. > tl;dr Updates too rare and computationally non-intensive. > > You are welcome to develop the idea and prove me wrong. I just think there > may be better uses of your time. :-) > > Either way, I can put it in as a game library developed with and for GS and GS games. > >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
