Re: OPENSTEP 4.2 vmware SVGA

[Pascal Bourguignon]

Frederic Stark <fred@almonde.com> wrote:
> I looked more closely to what happens, and things are not as simple as I 
> described.
> 
> The clock and the caret works perfectly (ie: they update in real time, 
> without any phantom). But fast-moving the mouse or moving large chunk of 
> graphics (ie: opening/moving/closing a window or scrolling) let large 
> 'bands' of the diplay untouched.
> 
> What I suspect is that vmware knows when the application touches the 
> framebuffer and blit it to the real screen a few milliseconds later. But 
> it looks like there is a race condition, and what is displayed during 
> the blit is not displayed onscreen. So parts of large transfers are 
> lost. I'll ask on the vmware newsgroups.
> 
> The MD5 trick (well, with a easier to compute CRC) could work. I could 
> take a look at what VNC does...

Yes, use an easier to compute value,  but it must still be a good hash
value of the  tile. There may have a lot of  regularities in pixels on
the  screen so  you want  to make  sure that  the slightest  change (a
symetry, a translation, ...) is  reflected into the hash. Of course, a
lot of  very different picture  will have the  same hash. We  can only
expect to  be able  to detect small  (in term of  information content)
changes.

Well if  you have  enough memory and  processing power, the  best hash
would be  the value itself, that is,  make a copy of  the frame buffer
and compare  the two  versions.  It doubles  the memory  accesses (and
more problematic,  the frame buffer  size is largely greater  than the
size of the caches). While comparing, you may want to try to determine
the smalest rectangle changed.


> Pascal Bourguignon wrote:
> > 
> > Frederic Stark <fred@almonde.com> wrote:
> > 
> >>Hi,
> >>
> >>Boring weekend. I took my OS42 CDs, vmware, the diff to the vmware 
> >>module of XFree86, the drivers example from OS42, a dozen of cup of 
> >>coffee and started to hack an OPENSTEP42 vmware SVGA driver.
> >>
> >>I am to the point where I get it running in 1024x768/24bits (yep, the 
> >>values are hard-coded for now). Code is _very_ ugly, as this is my first 
> >>OS42 driver (OS42 have no documentation on the DriverKit, and I can't 
> >>get my hands back on my 3.3 CDs). I can probably get something more 
> >>usable next week-end. I can release what I have for the impatient, of 
> >>course.
> >>
> >>The problem is that the DPS server never tell my driver when screen have 
> >>been written to, so vmware don't know when to update the real screen 
> >>(ie: there are 'phantoms' left in a lot of places). I don't think the 
> >>NeXT window server was ready to work with a 'buffered' device.
> >>
> >>Any idea about how I can solve that ? I can think about several solutions:
> >>
> >>1/ Don't care (by moving the vmware window, the 'phantoms' disapear 
> >>because vmware flushes the screen)
> >>
> >>2/ Implement a /dev device and a user-land utility to tell the driver to 
> >>flush the screen (every one second, for instance).
> >>
> >>3/ Get a PostSript master to try to hack WindowPackage.ps to know if the 
> >>server did something. Alternatively, I could try to patch the 
> >>WindowServer binary.
> >>
> >>4/ Play with mach memory to know if window server wrote to the 
> >>framebuffer. Issue a flush to vmware 1/10th of a second later. It must 
> >>be possible, but I have the slighest clue about how to do it.
> >>
> >>Any other trick ?
> >>
> > 
> > The best  solution would be something like  3/, to have a  hook in the
> > low-level    DPS     raster    routines.    That     would    be    in
> > /usr/lib/NextStep/WindowServer, but it's  death-row software, not free
> > software.
> > 
> > But it would  be enough to have your driver  flush automatically 10 or
> > 20 times  a second. Since flushing  to the screen could  be costly, it
> > may be interesting to divide the  frame buffer of your driver in tiles
> > and compute  a md5sum over  each tile, and  flush only the  tiles that
> > have changed.
> > 
> > Since there are the blinking carets, the clock, the cursor, the screen
> > will need updating continuously, in small parts of it at least.
> > 
> > The check sum computing frequency could be varied depending on whether
> > the tile or its neighbor changed recently or not.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------