wxWidgets on Mac ERASE_BACKGROUND events

[Ray Arachelian]

Hi Stefan,



Stefan Csomor wrote:
> 
> 
> 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 
> 

I'll certainly try that tonight, I'm away from the Mac at the moment,
however, I've had issues with CORE_GRAPHICS being enabled where it creates a
weird pattern on the 4 bit blits.  Hopefully that will not be an issue, but
I'll give it a whirl and see.


Stefan Csomor wrote:
> 
> 
> 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.
> 
> 

I have hooks into that, but don't directly grab the changes as displaying
them as the Lisa updates them would result in bad effects. i.e. the Lisa
writes to its display during the vertical retrace and often does strange
things, but always finishes before the scan lines start to display.  So
buffering these is the way to go.

That code also calculates a box around what's been changed, so by the next
video frame (60Hz cycle), I know the region that has been updated.  I do a
couple of other things.  To prevent too many blits, I keep a counter of how
many times the Lisa code has written to the video.  If it's over a certain
value, I force the update of the entire display.

I could blit to the memoryDC as the Lisa code writes to the video buffer,
that would get rid of the need for all of the region stuff as well as the
dirty buffer, but it seems to slow things down a lot.  I suspect that two
4x1 blits (i.e. one byte)
are far slower than some larger blit later on due to all the overhead of
setting up the call, but I could experiment some more.


I used to do full display Blits in the earlier code, but people on older G4
Mac's complained that it was very slow.  It flew on anything above 1GHz on
the Intel size, but even on a 1.4GHz G4 Mini, it was slow.  It seems a lot
of my emulator's user want to run it on older Macs, so, I can't quite write
them off. :-)


Stefan Csomor wrote:
> 
> 
> 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
> 
> 

That's what I do now.  The Lisa code updates its video buffer at will, then
when it hits the vertical retrace and it's time to update, the code compares
that to a 32K buffer and blits the changes onto the skin (or memoryDC
buffer).  It then sends a RefreshRect with a rectangle for that size.  The
code in OnPaint dispatches OnPaint_skinless or OnPaint_skins which does the
blit from the skin onto the display.



Stefan Csomor wrote:
> 
> 
> 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
> 
> 

That would work very nicely on my Macbook pro, but my G4 users with less
than 1GB of RAM will complain too much. ;-)

so for now, I'll run the code through a profiler and see where I can squeeze
a bit more out of, then tonight I'll try the cvs version of the code to see
if it will be able to stretch better.

Thanks much.  
-- 
View this message in context: http://www.nabble.com/wxWidgets-on-Mac-ERASE_BACKGROUND-events-tf3700448.html#a10360348
Sent from the wxWidgets - Dev mailing list archive at Nabble.com.