On 2013-05-29, at 01:07, tim Rowledge <tim at rowledge.org> wrote:

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

No, that's not what I meant. You want each top-level morph (and possibly others) to be backed by a texture in graphics memory. Those can be composited quickly by the GPU. Bits in main memory are not fast enough, CPU-GPU transfer is too slow.

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

The only issue is speed. You want to avoid redrawing.

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

I know, but things get muddled up if people don't know the underlying technical details.

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

Not if the final Squeak window image exists only on the graphics board with no quick way to access those pixels. The beauty of Etoys' collision tests is that it simply looks at colors on the screen. It can bounce off *anything*.

> Actually, don't Cairo-like libraries have 'A touching B' tests anyway?

Nope.

> If there are several Squeak windows then surely we should be able to navigate an eToys car across all of them? 

We should, I'm just saying it's harder.

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

They upload them to GPU memory (a.k.a. textures) and then just refer to them by id for drawing.

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


I'm pretty sure this won't buy you any speed.

- Bert -