Tim Rowledge <rowledge(a)interval.com> wrote:
> I forgot an important paragraph in my last note on this subject - and one
> that might just help the BeOS folks work out what is slowing them down.
>
> The reason that having the Display be in little-endian form and doing a
> pixel reverse for any blit where the Display is source and/or target is a
> poor choice is that the Display is involved in a _lot_ of blits. I forget
> the precise details, but at one time I had to trace something that lead me
> to notice that something like 20-50 times more blits were to the screen
> than there were display update cycles.
I've never measured it directly, but this is entirely consistent with timings
that I've done showing that the final "copy to screen" operation was only a few
percent of the overall display time. The reason for this is pretty obvious
when you think about it. Drawing a typical window involves
*lots* of small drawing operations, includine: the title bar, scroll bar,
fill color, borders, and the window contents involving a separate drawing
operation for each line of text. In both Morphic and MVC, the target of all
these drawing operations is usually the Display. Morphic postpones
copying the final result of all these drawing operations to the actual
hardware display buffer until the end to make the overal display update
look like a single atomic operation. This provides the illusion of
smooth, continuous motion that is essential for animation.
Re:
> On Acorn and Windows (possibly X11, though I haven't read the code enough
> to be sure) the Display is only copied to the glass when the appropriate OS
> event is received. At that time, and that time only, is the Dispaly bitmap
> pixel reversing done - which is why Andreas is quite right that the
> overhead is fairly low, as long as the OS merges small rectangles etc
> effectively and as long as we have to handle these events relatively rarely
> (~100 times/sec max) all is ok. If I understand the code correctly, the
> Mac updates the glass every time.(?)
Under MVC, that is the case. Under Morphic, the "copy to the glass" is
deferred until the end of the update cycle. Because of the way it batches
up display updates, the Windows VM window redrawing actually feels faster
than it does on the Mac under MVC. I was astonished when I first saw the
Windows VM because I just assumed it would feel slower.
Re:
> If you are doing a pixel reverse _every_ time you write to the Display, not
> to mention actually forcing a copy to the glass, then performance
> would probably suffer. Perhaps, just perhaps, this is what the BeOS code is
> doing?
Good point, Tim. A quick experiment would be to see if things look better
in a Morphic project, since Morphic does batching of display updates (if
you implement the deferrUpdates primitive, that is!). I like to use the
"BouncingAtomsMorph" as a display performance benchmark.
-- John
