SourceForge has been redesigned. Learn more.
Close

#68 improved framebuffer damage tracking

open
nobody
None
5
2004-07-23
2004-07-23
No

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
during drawing.

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.

improvements...

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?

drawback...

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.

also...

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
client anyway.

enjoy

Discussion

  • Nobody/Anonymous

    Logged In: NO

    i have a strange problem with this patch ... at bottom of
    the window i get a black row ... empty, but mac os x draw on
    it if i move the dock in the bottom part it is partially hidden

    however with this patch there is a serious speed up ... i've
    enabled graphical effects on dock and they are fast ... near
    the normal speed over a real mac!

    good work

     
  • Steven Noonan

    Steven Noonan - 2005-07-28

    Logged In: YES
    user_id=1103902

    Very nice. I followed the changes to the X11 file, and made a
    Win32 version. If anyone is interested, contact me and I'll
    submit it as a patch.

     

Log in to post a comment.