Am still back at Squeak 3.8; apologies if this has been fixed in more
recent versions. I've suddenly run into a really vexing problem in which the usual 100% bit-compatible behavior of Squeak is not quite there. I'm just about finished with evacuating Apple and moving my life to Linux. My desktop machine is Slackware 12.2, KDE 3.5. Everything works fine. My new laptop has a Radeon video driver, runs Slackware 13.1, KDE 4. I'd noticed some odd effects on the laptop in terms of some things showing up strange shades of gray when I expected them to be black. Now it seems I can figure out approximately when this happens: 16-bit forms. My 16-bit forms are showing on my 32-bit color on the laptop as if they were 32-bit forms with 16 bits of precision, or something of that kind; I'm certainly *not* getting 16-bit black showing up on the display as 32-bit black. When I pop on an SVG monitor to the laptop, the color anomaly occurs there too. Is there a preference I can set to fix this? This problem is going to really hurt if I want to present from my laptop. -Thanks, Jim |
On Sun, May 01, 2011 at 09:04:24PM -0400, Jim Rosenberg wrote:
> Am still back at Squeak 3.8; apologies if this has been fixed in more > recent versions. > > I've suddenly run into a really vexing problem in which the usual 100% > bit-compatible behavior of Squeak is not quite there. I'm just about > finished with evacuating Apple and moving my life to Linux. My desktop > machine is Slackware 12.2, KDE 3.5. Everything works fine. My new laptop > has a Radeon video driver, runs Slackware 13.1, KDE 4. I'd noticed some odd > effects on the laptop in terms of some things showing up strange shades of > gray when I expected them to be black. Now it seems I can figure out > approximately when this happens: 16-bit forms. My 16-bit forms are showing > on my 32-bit color on the laptop as if they were 32-bit forms with 16 bits > of precision, or something of that kind; I'm certainly *not* getting 16-bit > black showing up on the display as 32-bit black. When I pop on an SVG > monitor to the laptop, the color anomaly occurs there too. > > Is there a preference I can set to fix this? This problem is going to > really hurt if I want to present from my laptop. Jim, Can you please provide a snippet of code that illustrates the problem? Thanks, Dave |
In reply to this post by Jim Rosenberg
Jim Rosenberg wrote:
> When I pop on an SVG monitor to the laptop, the color anomaly occurs > there too. > I am new to Squeak but I did 15yrs IT Support, so perhaps can offer some small assistance. 1. Can you make a sample code snippet with five rectangles at 100%, 75%, 50%, 25%, 0%? Also please attach a screen snapshot of the result, so the pixel values can be observed directly by those troubleshooting it. 2. Is "SVG Monitor" a squeak package, a Windows program (which one), or a physical external monitor? 3. Do the gray artifacts affect any non-Squeak windows? cheers, Ben |
Rendering 16bits on 32bits deserve deeper analysis.
Last week I saw this 16bit pixel 16r7FFF, which is white with 5 bits per color, translated to 16r00F8F8F8, that is the same 11111 bit pattern shifted by 3 bits to fit on 8 bits per color. The bug I was tracking was the associated alpha channel 00 meaning 100% transparence, but the color bit pattern itself was surprising, I would have expected 16rFFFFFFFF. Nicolas 2011/5/2 Ben Coman <[hidden email]>: > Jim Rosenberg wrote: >> >> When I pop on an SVG monitor to the laptop, the color anomaly occurs there >> too. >> > I am new to Squeak but I did 15yrs IT Support, so perhaps can offer some > small assistance. > 1. Can you make a sample code snippet with five rectangles at 100%, 75%, > 50%, 25%, 0%? Also please attach a screen snapshot of the result, so the > pixel values can be observed directly by those troubleshooting it. 2. Is > "SVG Monitor" a squeak package, a Windows program (which one), or a physical > external monitor? 3. Do the gray artifacts affect any non-Squeak windows? > > cheers, Ben > > |
Reading these method comment is interesting:
Color class>>colorMapIfNeededFrom: sourceDepth to: destDepth "Return a colormap for mapping between the given depths, or nil if no colormap is needed." "Note: This method returns a shared, cached colormap to save time and space. Clients that need to modify a colormap returned by this method should make a copy and modify that!" sourceDepth = destDepth ifTrue: [^ nil]. "not needed if depths are the same" (sourceDepth >= 16) & (destDepth >= 16) ifTrue: [ "mapping is done in BitBlt by zero-filling or truncating each color component" ^ nil]. ^ Color cachedColormapFrom: sourceDepth to: destDepth So it seems we preferred having BitBlt zero-fill or truncate the color components... ... probably a case when making it fast > making it right in the mind of programmers. Nicolas 2011/5/2 Nicolas Cellier <[hidden email]>: > Rendering 16bits on 32bits deserve deeper analysis. > Last week I saw this 16bit pixel 16r7FFF, which is white with 5 bits > per color, translated to 16r00F8F8F8, that is the same 11111 bit > pattern shifted by 3 bits to fit on 8 bits per color. > The bug I was tracking was the associated alpha channel 00 meaning > 100% transparence, but the color bit pattern itself was surprising, I > would have expected 16rFFFFFFFF. > > Nicolas > > 2011/5/2 Ben Coman <[hidden email]>: >> Jim Rosenberg wrote: >>> >>> When I pop on an SVG monitor to the laptop, the color anomaly occurs there >>> too. >>> >> I am new to Squeak but I did 15yrs IT Support, so perhaps can offer some >> small assistance. >> 1. Can you make a sample code snippet with five rectangles at 100%, 75%, >> 50%, 25%, 0%? Also please attach a screen snapshot of the result, so the >> pixel values can be observed directly by those troubleshooting it. 2. Is >> "SVG Monitor" a squeak package, a Windows program (which one), or a physical >> external monitor? 3. Do the gray artifacts affect any non-Squeak windows? >> >> cheers, Ben >> >> > |
Free forum by Nabble | Edit this page |