Some performance notes

[Steven Swerling]

Rob Gayvert wrote:
> Steven Swerling wrote:

> Very cool. WxMorphicPanel has long been on my "things that sound really 
> cool but I have no idea how hard they are" list.
> Judging from the wxWidgets source and the Squeak VM code, it looks like 
> DDBs are used where possible, so they must be appreciably faster than 
> DIBs. Do you always need to convert a Form to a wxBitmap, or would it 
> suffice to draw it in a DC? If the latter, you might be able to do 
> something along the lines of ioShowDisplay in sqWin32Window.c.
> What's your overall scheme? Will morphs draw themselves on a WxCanvas? 
> And how will events get routed?

(sorry long response)

It turns out that form bits and WxBitmap bits are in the same format, so 
creating a WxBitmap out of a form is quite fast and easy -- if they are 
the same color depth. I haven't pulled off conversion when the Form is 
in a non-screen depth yet, and I'm busily stealing code from 
ioShowDisplay and friends to try to get this working. I was thinking 
last night that I might just defer this for now, since I want to get to 
the smalltalk side of the code soon.

Anyway, I can now turn a form into a WxBitmap. I rigged up a little test 
where it grabs a Form from the DisplayScreen object and blasts it onto a 
WxDC via a WxBitmap. Actually, I do it 100 times in a loop, sending a 
different form to the WxDC each time -- it looks to be pretty darned 
fast, although I havent formally profiled it. This code creates a brand 
new WxBitmap for each draw.

A variety of things I want to get working on the primitive side:

1. Patching part of a form to an existing WxBitmap (instead of creating 
a new WxBitmap each time). Required near term, obviously. The rest on 
the list may be deferred until after I get the smalltalk/morphic side 
working.
2. As you intuited, having a prim call that blasts form bits directly to 
a WxDC is likely doable and will be faster. Definitely on the todo list.
3. Deferred until after WxMorphicPanel is working, but on the todo list, 
is getting from a WxDC, WxBitmap, or WxImage to a Form.
4. As noted above, I've spent some time on getting forms of alternate 
bit depths to display (stealing copious code from ioShowDisplay), but 
I'll probably defer this if I don't get it working very soon.

 > What's your overall scheme? Will morphs draw themselves on a WxCanvas?
 > And how will events get routed?
My overall scheme on the Morphic side is to:
1. Create a WxMorphicWorldState that updates any WxMorphicCanvases on 
the same tick as the dipsplay update. I believe this is easy.
2. Create a WxPasteUpMorph that has an associated WxMorphicCanvas. This 
PasteUpMorph will behave in many ways like a World.
3. Create a WxMorphicCanvas (subclassed from WxCanvas, not squeak's 
Canvas). Details on reasoning follow. The WxMorphicCanvas will handle 
blasting formbits to the WxDC, and also handle adapting Wx 
key/mouse/drag-drop events into Morphic events.
4. I may or may have to give WxPasteUpMorphs there own WxHandMorph. 
Details below.

[The rest is just a more detailed explanation of the above 4 points]

1. Create a "WxMorphicWorldState" so that I can make a small patch to 
the methods update the main squeak World (which is a PasteUpMorph). The 
world state will tell it's WxPasteUpMorphs (there could be more than 
one) to update their WxDC on the same tick that the main display is 
updated. There are already Hooks for Nebraska in WorldState that can be 
altered for WxMorhicWorldState to update WxDCs instead of remote canvases.

2. Having a subclass of PasteUpMorph (WxPasteUpMorph), that has it's own 
"forceToScreen". Actually, the WxWorldState may come here to update the 
Wx display, or may go straight to the WxMorphicCanvas (I haven't decided 
yet, and don't think this is a crucial decision). One way or another, 
the WxMorphicCanvas winds up blasting the form bits of it's associated 
WxPasteUpMorph to its WxDC.

The code that sends the form bits to the screen may or may not use a 
WxBitmap -- depends on what I come up with down in the primitives. Since 
I've got most of Form->WxBitmap working *now*, I may just go with what 
I've got so I can start on the smalltalk side, then optimize this step 
later. How the WxMorphicCanvas gets the form canvas bits to the screen 
will be invisible to WxPasteUpMorph, so this can be optimized later.

Note that by WxMorphicCanvas, I mean a subclass of WxCanvas, not a 
squeak Canvas. I do not believe that having a special squeak canvas is 
the way to go. Just let them draw the way they always do, then, in the 
final step, instead of blasting the result to the screen, blast it to a 
WxDC instead. A side benefit of *not* using a special squeak canvas 
would be that most squeak drawing machinery that uses squeak canvases 
can be drawn on a WxDC. If it sets form bits, then it can be used by Wx.

I may have to finesse some of the code in WxPasteUpMorph so that it can 
act like a "world" in some ways. I'd like it to be able to show flaps, 
show a world menu on mouse click, etc.

3. Having WxMorphicCanvas adapt mouse and keyboard events into Morphic 
events and dispatch them to the PasteUpMorph. This could be tricky, or 
it could be easy, I'm not 100% sure. I've taken a pretty long look at 
this, and I'm hoping that I can just feed adapted versions of Wx 
key/mouse/drag-drop events straight into the pasteup morph. But I may 
have to give each pasteup morph it's own HandMorph and tinker with the 
event processing machinery in WxHandMorph. This may be naive -- a proof 
of concept version of this is critical enough that I will probably go 
staight to this code as soon as the Form->WxDC code is "good enough for 
now". But my initial tour of the event code makes me think this is 
doable (one way or the other) all on the smalltalk side.