Canvas transform bug when rendering text?

>>>
>
> David, Lukas, whomever else it may concern.
>
> Of course I turned out to be (partly) wrong when looking into it.
> Transform does indeed not work with alpha, but not because of bugs in WarpBlt as I assumed, but because FormCanvas always uses the Paint rule when rotating...
> Try the attached code, and you should get better results. (you probably want to use smoothing > 1 if displaying text with rotation other than a multiple of 90 degrees).
>
> This seems to be more of a generic problem though, looking at the number of places a= 32 ifTrue: [] check is made, I'll try to come up with a more consistent solution for a system-wide patch. (which amongst other things would also fix the black border appearing around a window while zooming back to old position when you drag and drop it outside main window)
>  
> Cheers,
> Henry
> <FormCanvas-transformByclippingToduringsmoothing.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> funny way to type code.
>
> Stef
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> Lukas
>
> On 9 April 2010 11:20, Stéphane Ducasse <[hidden email]> wrote:
>> funny way to type code.
>>
>> Stef
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> On Apr 9, 2010, at 11:28 AM, Lukas Renggli wrote:
>
>> I don't write code like this.
>
> It was a joke :)
> but I really like the visual effect
>
>> Rotating a window is just a good test to
>> see if works, because it calls all kind of different code.
>>
>> If you rotate a more complex window than a workspace, my system hangs
>> btw. So there must be other stuff broken there.
>
> oops
> with the fix too?

> Thank you Henrik, it looks like a huge improvement!  The attached
> screen shots help explain why I only said "improvement" instead of
> "perfect".  Look at the color of my translucent morph when it is
> upright vs. rotated.  The translucency is now preserved, which is
> great!  However, do you know why the color seems to lose so much
> saturation?
>
>
> 2010/4/8 Henrik Sperre Johansen <[hidden email]>:
>> On 07.04.2010 14:26, Henrik Johansen wrote:
>>
>> On Apr 7, 2010, at 1:45 49PM, David Harvey wrote:
>>
>> Hi list,
>> I'm writing a little charting morph, and while playing with  
>> rotating text
>> for axis labels came across something which I've noted in Morphs text
>> handling a couple of times.
>> If I apply a transform in a drawing operation, rotated text  
>> _appears_ to be
>> drawn twice, slightly offset, giving a scrappy bold look. It seems  
>> only to
>> do this when drawing on a form canvas that's backed onto the  
>> display: if you
>> pick and drag the morph, the text is rendered beautifully.
>> The test morph attached isolates the problem. The transcript  
>> logging is an
>> attempt to see what might be happening: looking at the output it  
>> appears
>> that there are circumstances in which the during: block is invoked  
>> twice.
>> Any thoughts?
>> David
>>
>> http://n4.nabble.com/Problem-with-TransformationMorph-td1691811.html#a1691811
>> Basically, transform doesn't work with depth 32.
>> Workarounds are described in the thread.
>> Cheers,
>> Henry
>>
>> David, Lukas, whomever else it may concern.
>>
>> Of course I turned out to be (partly) wrong when looking into it.
>> Transform does indeed not work with alpha, but not because of bugs in
>> WarpBlt as I assumed, but because FormCanvas always uses the Paint  
>> rule when
>> rotating...
>> Try the attached code, and you should get better results. (you  
>> probably want
>> to use smoothing > 1 if displaying text with rotation other than a  
>> multiple
>> of 90 degrees).
>>
>> This seems to be more of a generic problem though, looking at the  
>> number of
>> places a= 32 ifTrue: [] check is made, I'll try to come up with a  
>> more
>> consistent solution for a system-wide patch. (which amongst other  
>> things
>> would also fix the black border appearing around a window while  
>> zooming back
>> to old position when you drag and drop it outside main window)
>>
>> Cheers,
>> Henry
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
> <upright.png>
> <rotatedWithFix.png>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Michael Rueger a écrit :
>> On 4/10/2010 10:31 AM, Hilaire Fernandes wrote:
>>
>>> Will it allow us to have vector based UI element or is non sense?
>>
>> No, not non sense :-), that is exactly what it would allow.
>
> Yes, vector based UI is where we should move to keep in the course.
> Is it what you did for Sophie? If so, did you use some bitmap caching
> technic?