On 28-05-2013, at 2:15 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
> Note that there are two orthogonal problems: quality, and speed. For quality the vector graphics would help, for speed, not really. What we need for speed is hardware-based compositing.

Yes; that's what I'm hoping for to make the Pi more useful. 

> 
> The two can work well together. Each top-level morph (e.g. window) would render into a "surface", and all surfaces would be composited onto the screen. This gets rid of damage redraw, and allows extremely fast moving of windows. Optionally, submorphs can be backed by such surfaces too. It would be for the individual morph to decide whether to use bitblt or vector graphics to draw into its surface.

I'm not sure you'd *need*to make each top level morph be a separate surface, though it would be nice to be able to do that and have multiple host windows. Where have I seen multiple host window support before… hmm….
Surely there is no issue with having many morphs within a single surface, using paths and fills etc to do the drawing? Such libraries must be able to handle complex drawings or they'd be of very little use.

> 
> This is basically how any modern UI framework works, and the only way to make it really fast. There are just too many pixels even for a fast CPU.

Exactly what lead me to ask originally.

> 
> The price is added complexity, and less flexibility. There won't be easy/fast access to the whole display contents anymore. Developers will need to think in layers, not pixels. An Etoys car cannot easily bounce off a window in its way anymore.

As above, surely that isn't any more true than now; if there is a Squeak window then we know what is drawn in it and can find 'impacts' just as now. Actually, don't Cairo-like libraries have 'A touching B' tests anyway? If there are several Squeak windows then surely we should be able to navigate an eToys car across all of them? 

How much pain is there for using simple bitmap 'sprites' or 'icons' or whatever term you like? To the best of my (very limited in this area) knowledge, games still use a lot of bitmaps and so I'd be amazed if it wasn't practical to display them, move them, etc.

> 
> That said, it's still worth doing. 

I certainly think so. I hope we can get something done soon.

It seems to me there are two approaches that can be worked upon almost independently-
a) the low level connection to drawing libraries
b) the high level usage of the connection.

If Athens can drive the Balloon/B2DPlugin (and if that code still works as it should)  then we ought to be able to start using it very soon.Then when whichever low-level system is needed becomes available we would at least have a start on getting better. If I'm really lucky I might even be able to drive the RISC OS graphics system directly!

To see what I'm hoping to improve, take a look at the Scratch 1.4 system. There's a lot there that could be done with vector graphics rather than bitmaps. I would have thought that the script stacks in particular could be done much more nicely.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Oh bother" said Pooh, as he reached for the reset button *again*