Looks like some of the changes in trunk broke the mechanisms by which
the project view displays the project name:
I have not yet found the culprit, my suspicion is that this could be a side effect of antialiased font rendering. The core of the problem is somewhere in the drawing of a string morph on a fresh canvas. When you execute "(StringMorph contents: 'X') imageForm bits asArray" you will get different results in the current trunk image and in a 3.10.2 image, for example. I have not yet tried it in other images. Cheers, Hans-Martin |
Hans-Martin Mosner wrote:
> Looks like some of the changes in trunk broke the mechanisms by which > the project view displays the project name: > > I have not yet found the culprit, my suspicion is that this could be a > side effect of antialiased font rendering. > The core of the problem is somewhere in the drawing of a string morph on > a fresh canvas. > When you execute "(StringMorph contents: 'X') imageForm bits asArray" > you will get different results in the current trunk image and in a > 3.10.2 image, for example. I have not yet tried it in other images. Correct. I tried to dig in a little and the issue seems to be a result of the 16->32 bpp expansion of the anti-aliased font glyphs. An easy test case is this: self assert: ((StringMorph new contents: ' ') imageFormDepth: 32) bits first = 0. It would be interesting to see if this is an artifact of just the expansion (in the StrikeFont's glyphs) or if there is more than that. If anyone has a 32bpp version of one of the fonts I'd like to try. Cheers, - Andreas |
Andreas Raab wrote:
> Hans-Martin Mosner wrote: >> Looks like some of the changes in trunk broke the mechanisms by which >> the project view displays the project name: >> >> I have not yet found the culprit, my suspicion is that this could be >> a side effect of antialiased font rendering. >> The core of the problem is somewhere in the drawing of a string morph >> on a fresh canvas. >> When you execute "(StringMorph contents: 'X') imageForm bits asArray" >> you will get different results in the current trunk image and in a >> 3.10.2 image, for example. I have not yet tried it in other images. > > Correct. I tried to dig in a little and the issue seems to be a result > of the 16->32 bpp expansion of the anti-aliased font glyphs. An easy > test case is this: > > self assert: ((StringMorph new contents: ' ') imageFormDepth: 32) bits > first = 0. > > It would be interesting to see if this is an artifact of just the > expansion (in the StrikeFont's glyphs) or if there is more than that. > If anyone has a 32bpp version of one of the fonts I'd like to try. > > Cheers, > - Andreas The fix is in the trunk. There are several issues here. 1) StringMorphs can not be cached by the hand anymore. This has no relation with the problem you fond, but I found it while testing. So I added StringMorph >> hasTranslucentColor 2) ProjectViewMorph used #stencil:at:color: to draw the project name. Changed it to #drawImage:at: 3) We have a bug in BitBlt. When using #rgbAdd, alpha values are not actually added. What happens is more like (alpha1+alpha2)>0 ifTrue: [ 1.0] ifFalse: [0.0]. The strange thing is that the code seems to be right, and it works ok in the simulator. Just sent an email to VM-Dev asking for help on this. As a workaround, I defined StringMorph>>imageForm:forRectangle: to use a white background instead of a transparent one. Cheers, Juan Vuletich |
Juan Vuletich wrote:
> The fix is in the trunk. There are several issues here. > 1) StringMorphs can not be cached by the hand anymore. This has no > relation with the problem you fond, but I found it while testing. So I > added StringMorph >> hasTranslucentColor Makes sense. With anti-aliased fonts the caching logic is way to simplistic. > 2) ProjectViewMorph used #stencil:at:color: to draw the project name. > Changed it to #drawImage:at: Good choice for the moment. It beats an all-black rectangle ;-) > 3) We have a bug in BitBlt. When using #rgbAdd, alpha values are not > actually added. What happens is more like (alpha1+alpha2)>0 ifTrue: [ > 1.0] ifFalse: [0.0]. The strange thing is that the code seems to be > right, and it works ok in the simulator. Just sent an email to VM-Dev > asking for help on this. As a workaround, I defined > StringMorph>>imageForm:forRectangle: to use a white background instead > of a transparent one. How strange. I saw your post but didn't realize it was related to this issue. In any case thanks for the quick help! Cheers, - Andreas |
Hi Folks,
Andreas Raab wrote: > Juan Vuletich wrote: >> The fix is in the trunk. There are several issues here. >> 1) StringMorphs can not be cached by the hand anymore. This has no >> relation with the problem you fond, but I found it while testing. So >> I added StringMorph >> hasTranslucentColor > > Makes sense. With anti-aliased fonts the caching logic is way to > simplistic. > >> 2) ProjectViewMorph used #stencil:at:color: to draw the project name. >> Changed it to #drawImage:at: > > Good choice for the moment. It beats an all-black rectangle ;-) > >> 3) We have a bug in BitBlt. When using #rgbAdd, alpha values are not >> actually added. What happens is more like (alpha1+alpha2)>0 ifTrue: [ >> 1.0] ifFalse: [0.0]. The strange thing is that the code seems to be >> right, and it works ok in the simulator. Just sent an email to VM-Dev >> asking for help on this. As a workaround, I defined >> StringMorph>>imageForm:forRectangle: to use a white background >> instead of a transparent one. > > How strange. I saw your post but didn't realize it was related to this > issue. > > In any case thanks for the quick help! > > Cheers, > - Andreas Still playing with these issues, I realized that the second BitBlt pass (rgbAdd) for black text is always needed if the destination might have transparent pixels. It is true that we have nothing to add to r, g and b, but we need to add to alpha in the pixels used by the text. Otherwise they'll remain transparent. I just updated the trunk with this. I also removed the #properAlphaForBlackText preference. Finally, I added the correct alpha values to the colormaps used for 32bpp. However these fixes will not have any effect until the issue with BitBlt rgbAdd I found yesterday is solved. Only then rendering AA StrikeFonts over transparent destinations will work ok, and the workaround I did yesterday by adding #imageForm:forRectangle: to StringMorph (in Morphoic-jmv.170) will be good to remove. Cheers, Juan Vuletich |
Free forum by Nabble | Edit this page |