Re: [Fresco-devel] cache graphics

Caching in Fresco is a very simple trick. Whenever a Graphic wants its 
rasterization to be updated, it must call need_redraw(). Anything is 
implicitly cached; it's still on the screen! Unlike, say, an FPS, we 
don't continually rerender the display.

As for the potentially-evil-Graphic issue, your CacheGraphic::traverse() 
method has a pretty comment on the top claiming that it will never 
block. It then procedes to call into the Graphic--a method which may 
never return.

Sorry to fork the mail-thread on you like this, cinap, but I've also 
been thinking a lot about this issue. I don't think it's anything we can 
currently fix in our implementation.

I don't believe Fresco was designed properly. Look at these Fresco 
design requirements:

* Fresco must be entirely ignorant of the underlying pixel grid yet 
render perfectly on a given display. Instead, I propose that UI widget 
and text layout be aligned to the current pixel grid (if one exists). 
Yes, this means that Graphics will have different picking/drawing on a 
per-display basis.

* Fresco must be robust against all possible user or programmer errors 
even though we rely on potentially hostile code to do work for us. There 
are a few options. For example, Java is a technology that allows someone 
to run untrusted code. (Bad because we want to be language agnostic.) 
Alternately, we can move the Graphics into the server and only provide 
the client with a mechanism for modifying the composition of Graphics.

* Fresco should work with all programming languages. We employ CORBA for 
this. (In other words, it's protected by an SEP-shield.)

* Fresco must work transparently over a network. Again, we use CORBA.

* Fresco defines the scene graph to be a DAG, but there's nothing 
preventing it from becoming cyclic (to our detriment).

Gosh, did I miss any?

Historically, vintage Fresco never had the "protection against others' 
mistakes" issue, because it was a toolkit, not a server, so if you could 
crash it you were only crashing yourself. This issue, and whether the 
design is still appropriate hasn't been properly addressed.

If this is a full waterfall designed project then I'm asking to see us 
back in the requirements phase. What is Fresco supposed to achieve? What 
do we require from it? And please, please, can we learn from what we got 
wrong the first time? (the whole "fresco separates device from look 
rather that separating presentation from content" problem still rings in 
my ears.)

Nick Lewycky