From cells-devel at common-lisp.net Wed Sep 1 18:36:41 2004 From: cells-devel at common-lisp.net (Ira Childress) Date: Wed, 01 Sep 2004 20:36:41 +0200 Subject: [cells-devel] Hello Cells-devel Message-ID: <879666806909.10855@cells-devel@common-lisp.net> An HTML attachment was scrubbed... URL: From cells-devel at common-lisp.net Sat Sep 18 02:55:58 2004 From: cells-devel at common-lisp.net (Eddy Shipman) Date: Sat, 18 Sep 2004 04:55:58 +0200 Subject: [cells-devel] hiCells-devel Message-ID: <25112193347.63161@cells-devel@common-lisp.net> Cells-devel,' 75%off for all New Softwares. WindowXP,Photoshop,Window2003...etcMore http://QhSHhP.nenehbn.info/?4jC96lAjB8btmA4dD8pcp nope, not for me: http://pmj.applymed.biz/b.html -- afferent backlog bedimmed buildup nucleus danny bryce dimension bodhisattva memoranda alter electronic sparta From ktilton at nyc.rr.com Mon Sep 27 23:34:52 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 27 Sep 2004 19:34:52 -0400 Subject: [cells-devel] proposed refinement of lazy cells Message-ID: <4158A39C.8000203@nyc.rr.com> I have been working on Cello and seem to have run into a problem arising from the Cells sub-system, specifically the "awakening" process which forces all non-lazy cells to be evaluated. I have a slot which cannot be evaluated just any old time, it needs the right active OpenGL context (the containing window's). I /could/ have an "active" cell on the window itself and turn it on during GLUT callbacks, but that would be inefficient and a silly way to achieve something more elegantly (I think) conceived of as laziness: do not calculate this until asked. (The specific is the building of the OpenGL display list for a widget.) Unfortunately, the lazy option as currently set up will not work, because the slot never gets sampled if no containg widget is forced to rebuild its own display list. (the neat thing is that simply rebuilding the named display list causes the Right Thing to happen when the containing display list next gets kicked off.) Currenty laziness has two manifestations: cells are not awakened artificially, and change propagation stops at them. display-lists need to avoid the artificial awakening but not change propagation. Since I can imagine another cell requiring awakening but not change propagation, I am considering making the lazy boolean into a code, with legal values: :until-asked do not awaken artifically, but once asked stop being lazy :after-awakening awaken artificially, but do not propagate change automatically :always, or t current semantics, aka both I guess i will just go ahead since I am not breaking anything, but comments/questions are welcome. kt -- Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film From ktilton at nyc.rr.com Wed Sep 29 05:58:45 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 29 Sep 2004 01:58:45 -0400 Subject: [cells-devel] Cello fixes for FTGL Message-ID: <415A4F15.6010708@nyc.rr.com> CVS willing (I have my doubts), Cells and Cello have now been updated with changes to resolve some deadly problems with FTGL when combined with display lists. The Cells change had to do with enhancing the "lazy" option to be more of a code than a flag: one now has options :once-asked, :until-asked, and :always (alias t). Aside: I was surprised to see I had done this originally as an option on a formula for a slot. Seems to me it should be a slot option. ie, that when one needs lazy it will because the slot itself needs that behavior, no matter what the formula. So we'll put a "watch" on this design decision,which I left as is for now. making display list calculation lazy (until asked) solved the problem with extruded fonts. Texture fonts were fixed by hacking FTGL in ways which turned out to be in testing already for FTGL v2.1 -- ie, I ran into this at the same time as others and happened to come up with the same fix. The problem was pretty subtle, so I will spare you all unless someone asks for the deets. Pretty much just a deep issue with display list generation. Anyway, it now seems as if FTGL is back under control. Note that all this started when I went for the big performance enhancement of using nested display lists for all imaging. That interacted badly with some FTGL design decisions which have now been fixed or worked around. kenny