this is a working version of my method of damage
tracking, which i mentioned on the pearpc-devel list a
couple months ago.
it's cleaned up a bit since then - not perfect, but
what's the point. very tiny percent of time is spent
in the drawing thread anyway.
patch supports SDL and x11 only. i don't have a win32
build environment, but i'm sure to add a win32 loop is
just as easy as SDL was - if someone wants it, i'll try
and make it as well.
objective of this patch...
get rid of the comparison/branch in the gcard_write_x()
functions to update the damage-tracking vars.
fix the worst case scenario of a whole screen redraw
even if only small data is changed at the top and
bottom of the screen (for example, spinning cursor at
the top and boucing icon in the bottom of an OSX
session will not draw the whole screen with this patch)
a nice sideeffect of this patch...
it removes the race-condition which is mentioned in the
drawing threads, where updated pixels could be missed
how it works...
the frame buffer is cut into 'spans', which are (in
this patch) 128kbytes long. a table of ints for span
'damage' is kept, and the offset into the damage table
is screenaddr >> 17. when the drawing thread runs, it
looks for spans which need to be drawn, calculates
proper first_line, last_line for the span, and draws
it, then decrements that span's damage.
calcualte the span-count only on mode changes
create a table to convert span# to first_line, last_line
check for consecutive damaged spans and call the blit
functions only as many times as needed.
better locking/unlock of the sdl surface?
128kbytes i came up with because it worked well to get
near 16-line spans on a 1280x1024x32bpp screen. since
the spansize is done with a bitshift, it's not very fun
to make this dynamic, so a good size that fits most
common resolutions is in order, but 128k seems good for me.
in io.h i replaced the framebuffer range check with
(addr & 0xff000000) == IO_GCARD_FRAMEBUFFER_PA_START
might be some gain there
really some of this is pointless since there are
probably many hundreds JITC opcodes per pixel in the
Log in to post a comment.