[cells-devel] observer design question

[Ken Tilton]

I should have added more notes:

> This is an interesting case where we can get some efficiency where the 
> engine we are driving allows it. DHTML lets us change a specific node in 
> the DOM without resending a whole page, OpenGL lets us rebuild a display 
> list and have it take effect whenever any larger display list calls it:
> 
> (defmd ogl-node ()
>   (dsp-list
>      (c-formula (:lazy :until-asked)

"lazy" to start because we cannot build a display list until the opengl 
context gets established. Eager thereafter because (I was wrong, we do 
not need to artificially sample each list on each display call to get 
the invalid lists rebuilt) we want propagation of any releavnt change to 
kick off the rule to get the display list rebuilt.


>         (without-c-dependency
>             (map nil 'dsp-list (kids self)))

Here I am getting kids ready before I myself build my list: an OpenGL 
list can recursively /call/ other lists, but we can /build/ recursively, 
so I sample all my kids before building. I do it without-dependency 
because this is the issue Andy raised: a sub-node changing does not mean 
we need to resend the parent node.

>         (let ((display-list-name (or .cache (gl-gen-lists 1)))) ; #1
>             ;---start building this list -----
>             (gl-new-list display-list-name gl_compile)
>             (ix-paint self)
>             (gl-end-list)
>             ;---end building
>             (setf (redisplayp .og.) t) ; Note #2

I forgot to explain that normally we would have an observer on the slot 
trigger the redisplay, but these slots do not change in value, they 
mutate the display list definition on the OpenGL side, so we have to 
trigger the redisplay differently. And this is just a bit of global 
state that needs to get set /someplace/, no harm if a hundred lists say 
"redisplay!".

kt

>             display-list-name))) ;; always the same once allocated
> 
> #1 display-list-name (actually just an integer) is like an OpenGL object 
> ID. When larger structures render, they render kids by "calling" the 
> kids' display lists by these names. gl-call-list or something.
> 
> #2 notice that this rule mutates the display list, it does not allocate 
> a new one. (The whole scheme breaks down if we do that.) So we will 
> forever be returning the same "name" and so the Cells engine will not 
> see any change. Observers will not run and (crucially) users will not 
> get invalidated. This is way cool because this is exactly what we want. 
> The only dependencies arise during that call you see to IX-PAINT. If I 
> reference any other cell and that changes, then when the name slot gets 
> sampled Cells will kick off the rule to rebuild the list.
> 
> When do they get sampled? I think the display callback runs down the 
> visual hierarchy sampling each node's list to get it rebuilt before 
> runnning down it again to actually render -- you cannot build a display 
> list and render at the same time.
> 
> So it is both a little awkward yet strangely Cells-friendly.
> 
> kt
> 
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel
>