Hi
I am on vacation right now, but I here's a quick response to the changes:
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
1a) "SIMD": i have tested it under linux and windows and it works (although i am a bit disapointed of the performance-gain; unfortunately i have no SSE2 machine at hand so i haven't tried this yet); however, i have not tried to compile it under osX yet.
In my experience MMX is so poor that it's not even worth the effort. Not only is it only 64bits wide, it cannot do single cycle ops and well tuned scalar code will come close or match it with a decent compiler. SSE has C intrinsics much like Altivec which would greatly speed development and aid readibility about 1 billion percent - I know that VC++ and ICC work with them, but check GCC as well. Unless you can really tweak the hell out of the asm, it's better to use the intrinsics anyway as the compiler will do a lot of the little nicities for you. It's pretty easy to write very bad assembly.
1b) "multiple_window": (there is also a TAG with this name, so beware!) this separates the functionality of [gemwin] (which has vanished) into 2 objects [gemcontrol] and [gemwindow], where [gemcontrol] is the interface to the rendering-engine (GemMan) and [gemwindow] handles the window-management.
This is a pretty huge change, and it should be a working branch or the objects should be built as entirely separate objects. It does break every patch and version of GEM currently out there, which is a problem.
Overall, this is a good idea and the functionality is a welcome advancement, but the direction of development needs some discussion. I would suggest keeping the gemwin object and just adding some arguments to it to create multiple windows ([gemwin window1] to make a window called 'window1' or something). [gemcontrol] isn't as bad idea, but it could be potentially confusing if one object manages many windows at once.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.