[wx-dev] RE: wxWidgets on Mac ERASE_BACKGROUND events

[Stefan Csomor]

Hi Ray

thanks for the details (and congrats to this great app, I've just
installed it to better understand the issues) , I'll try to give a few
ideas

> But even with all that, it's still too slow.  I'm not sure where else
> I can
> optimize things.  I suspect that the small 4 byte blits are a bit
> more
> expensive than they need to be... I've tried to use the native
> scaling
> features, but they result in a very ugly display. i.e. going from 364
> lines
> to 500 lines results in some lines not being drawn, no antialiasing,
> etc.
> 
> Ideally I'd want a fast method to Blit a scaled image stretched on
> the
> Y-axis with anti-aliasing to be built in to wxWidgets, but that's not
> available.
> 
> I suppose I could try to directly maniplulate the wxBitmap
> representing the
> Lisa's display, but that would break  both portability and C++ rules.
> :-)

would switching to CVS HEAD be an option ? there is a stretchblt
functionality there, which at least on OSX uses the built-in
anti-aliasing 

> handling seems to be another issue.  Is there some way to control the
> frequency of how often the mouse handler gets called?  (I'd give up
> more CPU
> time if the mouse was more responsive, but trying that results in a
> very
> slow emulation and it still doesn't fix the mouse/display latency.)
> 
> Other ideas:  Would I be better off by forking a thread for my CPU
> handler?
> If I did that would I still be able to update the bitmap that
> represents the
> display from the CPU thread with the appropriate locks?  Would I be
> able to
> call Refresh from the CPU handler thread, or should I pass a message
> to
> something else which in turn would call Refresh?
> 
> I suppose it would help on a multicore or hyperthreaded system, but
> I'm not
> sure if that's the right path to take.
> 
> Is there anything else I can play with to tweak the timing?

I think the most important thing is to make sure the display code is
fully optimized / lazy. Are you alerted when the Lisa writing into the
videobuffer ? or could you setup such a code ? perhaps it would be
easier to just blit at the very moments these changes take place, just
for the pixels involved, so that my_memDC is always current. Then just
issue a Refresh(). 

In the OnPaint handler I'd just do a single full blit of the entire
screen.

alternatively you might also just dirtymark the areas of the videobuffer
that have changed via a simple scheme and update these in the OnPaint
handler in the memorydc

I'd also think that using the 16 MB bitmap with 8 bits at the time is
not an issue anymore with current computers, but the code would get
quite a bit simpler and faster I'd assume.

Best,

Stefan