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 <enrytheer...@gmail.com> 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! 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. 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? - Why /exactly/ do you assume it would be better than existing approaches to rendering? - What exactly do you presume will benefit from AI in the rendering world? Why exactly? - Will this make it faster and easier to write GNUstep applications? How? - Will this make GNUstep applications faster? How? By how much? - Will this make GNUstep's rendering path easier or harder to understand? If harder, is this worth the maintenance burden? Summary: What exactly are you planning to write with these new APIs? 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. > 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. On Tue, Dec 16, 2014 at 4:50 PM, Johan Ceuppens <enrytheer...@gmail.com> 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 -- Ivan Vučica i...@vucica.net
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
