|
Notes |
|
|
(0002690)
|
|
ducasse
|
|
09-17-05 20:20
|
|
|
How can I reproduce the bug.... |
|
|
|
(0002703)
|
|
wiz
|
|
09-19-05 05:33
|
|
Hi Stef,
The easiest way to check it out is to load the cs I was working on when I needed to fix it. I've uploaded PopupThumbnails-wiz.4.cs . If you try this on the ImageMorph default form it doesn't look much like the default imageMorph until the fix cs is loaded.
Cheers --Jer |
|
|
|
(0002830)
|
|
wiz
|
|
10-12-05 04:42
|
|
Uploaded ColorFormScaleRotFix-wiz.1.cs .
This corrects the rest of the methods that needed correction.
From the preamble:
This is a fix up to allow color forms to be scaled and rotated w/o losing their class or their colors.
This follows the pattern set by filpBy:centeredAt: (ar 1999). We fix the main methods (the ones that call warpbit) and leave the feeder methods alone. |
|
|
|
(0002963)
|
|
andreas
|
|
10-25-05 07:42
|
|
|
I have fixed the problem in the latest version but in a rather different way, by making such ColorForms return 32bit deep forms. Contrary to your solution this will always work at the expense of some memory being wasted. This seems to be a safer way of going about this issue - it leaves us room for optimizing for memory use now. |
|
|
|
(0002995)
|
|
wiz
|
|
10-27-05 06:57
|
|
Arrrgh. (What's the emoticon for a wounded sigh?) A 32bit deep form is still a form and not a colorForm. What if the end result that you want is the colorForm? ColorForms are more important to elegant graphics than squeak acknowledges or is aware of. You sometimes want to paint by numbers with a limited pallette.
The space needed might not be a "small amount" in all applications. You might want space savings of a colorForm when doing animation stuff.
My larger unhappiness is with the loss of flexibility of the one way mapping of the Colorform into the Form.
Also could you explain when what you did with 'filpBy:centeredAt:' and I did with the other methods won't work? You must be seeing something I don't. |
|
|
|
(0002996)
|
|
andreas
|
|
10-27-05 07:24
|
|
wiz - First I'm going to resolve this bug again, since (as far as I could reproduce it) the bug has been fixed. If you think the bug has not been fixed, please provide some evidence to the contrary.
Second, as to how the bug was fixed, it was fixed in the most general way possible, by converting the form into a 32 bit form (which is not lossy if you accept 8bit color components). Note that this leaves a client with a variety of possibilities if you care about, for example, you can just do a #colorReduced on the result of the magnification, e.g., "(aForm magnifyBy: 2) colorReduced" will preserve the colors just nicely.
Third, as for why it doesn't work in the general case, try:
((ImageMorph classPool at: #DefaultForm) magnifyBy: 0.5) colorsUsed size
You will notice that the colors used in the resulting (32bit) form (574) are more than can be represented by a ColorForm (limited to 256 colors). In the general case, due to supersampling you have to assume that all colors can possibly be constructed, there is absolutely no guarantuee that the set of colors is limited to the ones you're inputting.
Fourth, you can limit the number of colors by restricting the "cellSize" to one, e.g., disable the supersampling done by WarpBlt. However, that is a severe restriction, and I see no good reason why we should disallow super-sampling on ColorForms, in particular because the methods in question can be given the "cellSize" as an extra argument (so if you care use a cellSize of 1). Which ultimately brings us to...
Fifth, if you wish to preserve the ColorForm'ness in those special cases where it is indeed possible to preserve it, please submit code that does so. I'll happily integrate it.
Right now I see the situation as: The bug is fixed and if you need a ColorForm you can use #colorReduced, so everything else is a mere space optimization. If you need this optimization I'll be happy to integrate it, just submit a feature request with the code that does it. |
|
|
|
(0003515)
|
|
wiz
|
|
01-16-06 21:17
|
|
Hi Andreas,
I am reopening the issue again. (Sigh)
In the lastest 3.9a (6713) the problem is still evident.
In a workspace evaluate:
-----
[ :m | m image: (m image magnify: m image boundingBox by: 2 ). m changed ]
value: (ImageMorph new openInWorld center: Display center )
----
this will get a color mangled copy of magnified image morph.
I realize you probably have a fix and it has not gotten into 3.9a yet.
I can't offer any patches until I see at least what you have done.
Could you upload your fixes to this report? (And get the release team what they need to update 3.9a?)
Sorry for the bother. Thanx for your help.
Your is service, -- Jerome Peace |
|
|
|
(0003518)
|
|
andreas
|
|
01-17-06 01:03
|
|
Did you try this with the latest version in the repository http://source.squeakfoundation.org/Graphics.html [^]
? I haven't pushed the latest version over to the 3.9 inbox so it is quite possible that the current 3.9 doesn't include that fix yet. |
|
|
|
(0003538)
|
|
wiz
|
|
01-18-06 21:04
|
|
Hi Andreas,
The most recent release I found was Graphics-ar.25.mcz. I'll try working w/ that.
Thanx -- Jeome Peace |
|
|
|
(0003593)
|
|
wiz
|
|
01-22-06 08:23
|
|
Hi Andreas, I looked thru the code and did some tests.
I found a couple of the scale parameters that were being passed were the reciprocal of what they were supposed to be.
I'm uploading a checkpoint changeset (FormFlagsNFixes-wiz.3.cs) that has the fixes along with some other stuff. Use it as a guide not a final say.
I've also seen a lot of code that looks like it could be the source of some of the rounding bugs I've been hunting. Some of the flags are in this checkpoint.
Please look at the preamble. The testing doits for the rotations are there.
Cheers,
Yours in service, -- Jerome Peace
|
|
|
|
(0003707)
|
|
wiz
|
|
02-07-06 08:53
|
|
|
Uploaded FormMagnaRotaFix-wiz.1.cs which are the fixes for the reciprocal ratios. |
|
ScaleColorFormFix-wiz.1.cs [^] (848 bytes) 09-16-05 02:48