[Vm-dev] What a surface mess !!!

[John McIntosh]

> Nicolas

There is another bug you should be aware of. Bitblit aka the drawing engine will read one byte beyond the edge of the pixel rectangle to provide transparency/blurring. Oddly this causes a page protection fault if the screen area is a multiple of the Operating System page size and the drawing area maps the end byte of the blit Say the screen area is 4096 byte, the prefetch will read the 4097 byte causing the fault because likely you don't owe that page, due to the VM manger being helpful in preventing out of bounds read/write operations off the end of your allocated memory.  Especially true on OS X.

A decade back for Sophie we looked at fixing it but simply adjusting the algorithm didn't work as expected(drawing artifacts when swirling the mouse cursor) Or range checking during the copy of each raster line was very expensive.



Sent from my iPhone

> On Nov 11, 2016, at 18:27, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> Hi,
> I'm looking at various surface plugins... It's a mess.
> 
> There is a mix of int/long/void * in the various declarations.
> What is very nice, is that they are all of equal size in ILP32 convention, so we can be very careless and ignore all the compiler warnings.
> Well, until we try to port to LP64 or LLP64...
> 
> When trying to untangle that mess, I see there is the handle/pointer/ID confusion.
> 
> SurfacePlugin.h expects a surfaceHandle to be a void *, and declare that it will pass that type to the four functions (getSurfaceFormat,lockSurface,unlockSurface,showSurface).
> 
> Of course, the comment a few lines below does not quite agrees, it says it's rather a long.
> 
> The functions defined in end of same file and which are used by interpreterProxy interface declare the surfaceHandle as long...
> 
> And sqMacWindow.c uses an int handle!!! It's used as an ID.
> I would have thought that the conversion SurfaceID -> SurfaceHandle would have occured a bit sooner, but here no.
> 
> Same mess for the other parameters, x,y,w,h,pitch,isMSB, they are either declared int or long... It may work by pure luck on little endian machines when we pass args by registers, and SYSV X64 convention uses a lot of these, or when each arg passed thru stack is 8-bytes aligned, and when the caller has the longer type. But that's dramatically wrong when we pass a pointer to such data, we'll then get pure UB related to uninitialized MSB...
> 
> I'm going to fix that, don't be amazed if you see a bit of traffic in the next hours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161111/993f1e85/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2651 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161111/993f1e85/attachment-0001.bin>