John, Bravo, that was it exactly. I have re-merged your 64-bit updates and added the j = 0 fix to the read and write primitives. All seems well now when compiled in either 32-bit or 64-bit mode.
Eliot, Changes attached for inclusion in oscog. Two methods are affected.
Bert, This should make things healthy again for EToys after the next VM build.
Dave
On Fri, Oct 08, 2010 at 02:42:12PM -0700, John M McIntosh wrote:
Ah, ok I see
for(i = 0, j = 1;
I think the jpeg embedded C code is then offsetting by j = 1 to ensure it skips the first header word when we did the formBits :=self cCoerce: (interpreterProxy fetchPointer: 0 ofObject: form) to: 'unsigned *'.
however the formBits := interpreterProxy firstIndexableField: formBitsOops. skips over the header word for the oops and the embedded C code then does formPix = formBits [ ((pcinfo->next_scanline) * formWidth) + j ];
thus offsetting from (1) versus the required (0).
So can someone take the 64bit changes and alter the
for(i = 0, j = 1;
in primJPEGReadImage: & primJPEGWriteImage:
and see what happens?
On 2010-10-08, at 12:12 PM, Bert Freudenberg wrote:
So I tracked it down to Mac version 4.2.3 that is broken, whereas 4.2.2 was still fine.
The Windows 4.1.1 also has the broken plugin, 3.11 was still fine.
Same for Linux 4.0.3, it's broken.
According to John's release notes he switched to VMMaker 160 in 4.2.3, and also noted
**** This VM includes some features not in VMMaker yet ***** (f) JPEGReaderPlugin, work to make 64bit clean
So maybe this is where the problem comes from.
The latest 4.x VM (4.2.5) still has the bug. I'm attaching a jpeg exhibiting the problem. It "wraps around" when imported, you can see the former right edge on the left. The code pasted below also shows the problem.
Would be great if we could still fix this, currently Etoys ships with the broken VM ...
- Bert -
On 27.09.2010, at 11:45, David T. Lewis wrote:
I think that John made some changes that would have entered the VMMaker updates as of VMMaker-JMM.166 (March 2010). In addition, three methods are different between the Cog branch and the main branch:
#primJPEGReadHeader:fromByteArray:errorMgr: #primJPEGReadImage:fromByteArray:onForm:doDithering:errorMgr: #primJPEGWriteImage:onByteArray:form:quality:progressiveJPEG:errorMgr:
Looking at the method time stamps I'm guessing that there was some fix made by Andreas in 2006 that is present in the Cog code base but not the main VMMaker. My guess would be that we should be using the Cog versions, and merging John's March 2010 updates into this.
I just happen to be part way through converting the plugins to use pragmas to match Cog. The updates for primitives should be done in a couple of days, after which it will be easier to spot differences like this.
Dave
On Mon, Sep 27, 2010 at 05:22:43PM +0200, Bert Freudenberg wrote:
Hi,
have there been changes lately to the jpeg plugin?
On a Mac 4.2.4 VM I see an off-by-one error, all pixels are moved to the right, the first pixel is transparent. On a Mac 5.8.1 Cog VM it works as expected though.
Here's my little test:
(JPEGReadWriter2 formFromStream: #[16rFF 16rD8 16rFF 16rE0 16r00 16r10 16r4A 16r46 16r49 16r46 16r00 16r01 16r01 16r01 16r00 16r48 16r00 16r48 16r00 16r00 16rFF 16rDB 16r00 16r43 16r00 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rFF 16rC2 16r00 16r0B 16r08 16r00 16r01 16r00 16r01 16r01 16r01 16r11 16r00 16rFF 16rC4 16r00 16r14 16r10 16r01 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16r00 16rFF 16rDA 16r00 16r08 16r01 16r01 16r00 16r01 16r3F 16r10] readStream) bits first hex
On 5.8.11 I get 16rFF808080 as expected, on 4.2.4 I get 0.
- Bert -