Re: [Fresco-devel] cache graphics

On Sun, Jan 04, 2004 at 12:18:10AM -0500, Nick Lewycky wrote:
> 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.

it calls into itself... and it trust itself...
the point is that it only calls into the untrusted child-graphic from its
thread...

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

this only can be done if the structure of the scenegraph is managed by
trusted code in the server.

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

you mean the current architecture of fresco is a dead end (for this issue)... 
and we should go back together on the big-round-table...
ok... lets do 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

many thanks for this fast answer!

> _______________________________________________
> Fresco-devel mailing list
> [email protected]
> http://lists.fresco.org/cgi-bin/listinfo/fresco-devel

cinap_lenrek