Folks,
I'm seeing really weird BitBlt artefacts on my Windoze machines, and I can't fix it myself. The following is reproducible on all my machines, systems (NT/98) and VMs (3.0bld2, 3.0bld1, even 2.8bld-a2). I'd be curious whether Mac and Unix users get this, too:
Open a *vanilla* 3.0final image, and do not move, collapse nor obscure the "Welcome" window. Open a workspace and do:
| p q | p _ 394@261. q _ p + (200@0). Display copy: (p extent: 100@100) from: Display to: q rule: 3.
and whip out a MagnifierMorph to examine the result. Here, the first two columns look rather odd. (The "f" of the "for" is missing many bits, while the "e" of the "The" is compressed horizontally.)
I thought I was hallucinating -- this couldn't be, someone would have noticed long ago. But the nastiness nastily varies with Squeak's bit depth. With a graphics card in 32bit mode, the Squeak modes behave as follows:
32 bit: effect is hardly noticeable, the "e" is copied, but 1 bit shorter (top line: 2 pixels instead of 3),
16 bit: the "e"'s top line is only 1 pixel wide,
8 bit: the "e" is crippled,
4 bit: the "e" is copied intact, but now the "o" of the "for" is missing completely,
1 bit: perfect.
I have rummaged through my archive, and a 2.5 VM (win build 6) with an accompanying 2.5f1543 does not show these artefacts, at any bitdepth.
Cheers, Helge
On Tuesday 27 February 2001 13:56, Helge Horch wrote:
I'm seeing really weird BitBlt artefacts on my Windoze machines, and I can't fix it myself. The following is reproducible on all my machines, systems (NT/98) and VMs (3.0bld2, 3.0bld1, even 2.8bld-a2). I'd be curious whether Mac and Unix users get this, too:
I didn't try this with a vanilla image, but I am seeing similar distortion on the first couple of columns of pixels using 3.1 and the 3.0pre2 Unix VM.
Helge Horch Helge.Horch@munich.netsurf.de wrote...
I'm seeing really weird BitBlt artefacts on my Windoze machines, and I can't fix it myself. The following is reproducible on all my machines, systems (NT/98) and VMs (3.0bld2, 3.0bld1, even 2.8bld-a2). I'd be curious whether Mac and Unix users get this, too:
Here's a fix, which should soon make it through the update process.
- Dan
As it says in the preamble... ----------------- Fixes a bug introduced in changSet 1945BitBltSpeedup, and discovered by Helge Horch. It had resulted in different results in the upper and lower copies displayed during the following loop (the upper copy results from a blt with src==dest, delta y = 0, and delta x > 0, the only case for which the horizontal loop must proceed from right to left):
| p q | [Sensor anyButtonPressed] whileFalse: [p _ Sensor cursorPoint. q _ p + (200@0). Display fillWhite: ((q extent: 50@60) expandBy: 10). Display copy: (p extent: 50@30) from: Display to: q rule: 3. Display copy: (p extent: 50@30) from: Display to: q + (0@31) rule: 3. (Delay forMilliseconds: 200) wait].
This change purports to fix the problem for all color depths.
squeak-dev@lists.squeakfoundation.org