[GEM-dev] CVS: checkins and notifications

IOhannes m zmoelnig zmoelnig at iem.at
Thu Aug 19 11:44:38 CEST 2004


chris clepper wrote:
> Hi
>>1a) "SIMD":
> In my experience MMX is so poor that it's not even worth the effort.  Not only
you couldn't have told me earlier ;-) (i even guess, you did!)

> 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.

actually there are intrinsics for MMX, SSE and SSE2, supported by icc, 
gcc and vc7 (and vc6 if you have the "processor pack"); i really did 
write the code for gcc (and was surprised that it worked so well under 
windows then)
and indeed: i don't think that i would *ever* have written any line of 
assembler for MMX.



>>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.  

i thought it would be possible to stay compatible with older patches.
the magic is in the abstractions folder that provides a 
[gemwin]-abstraction holding [gemcontrol] and [gemwindow].


> 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). 

indeed this would have been another good idea too.
the problem that i see is, that you would have a rendering-engine (the 
current GemMan) for each window. one of the problems arising here, is 
that auto-updating objects (like pix_film or particles) will have 
serious problems to stay "in time". the current solution in the 
multiple_window branch is to control the frame-rate centrally (this is: 
each window renders at the same rate, which might be a problem) and the 
use of display-lists sharing, which calls the render-object of each 
[object] exactly once per rendering cycle (but of course, display-list 
sharing might not really work everywhere).

> [gemcontrol] isn't as bad idea, but it could be potentially confusing if one
> object manages many windows at once.

the idea is, to use pd's messaging system for controlling. imagine a 
patch with 3 [gemwindow] objects, 2 of which are connected to the sole 
[gemcontrol]. you create 3 windows by sending a "create"-message to the 
  [gemwindow]s and turn rendering on by sending "1" to [gemcontrol].
2 of the windows will render the scene, the 3rd (which is not connected) 
  will stay blank.

i guess this is more like pd's concept of sources and sinks (you could 
compare [gemwindow] to [dac~])

all the [gemcontrol]s will control the same rendering-engine (if you 
turn one gemcontrol "on", you turn all of them on)

i even think it would be clearer than it used to be, as now you can have 
multiple [gemwin]s and send concurring messages to each of them which 
all take effect on the same window (e.g: multiple objects managing a 
single window)

the only problem that could arise is indeed, if one has multiple 
[gemwin]s in their patch.
this will eventually produce multiple windows (which is a minor issue)
but if you were using one [gemwin] to create/destroy and another one to 
set the fog-density this will really break the patch.





and thanks for being not grumpy ;-)


mfg.s.f.as
IOhannes




More information about the GEM-dev mailing list