Hi,
should it be a valid state for the World (not an arbitrary PasteUpMorph, but one that #isWorldMorph) to have a transparent TranslucentColor? The current implementation does not forbid this.
I know this would not make much sense, but I discovered a quite interesting rendering problem:
World color: (Color darkGray alpha: 0.2). MagnifierMorph new openInWorld. bg := BackgroundMorph new addMorph: Morph new; position: 200 @ 100; extent: 128 @ 128; "works" openInWorld.
Hover the BackgroundMorph, and the magnifier will work as expected. Now do:
bg extent: 128 @ 127. "fails"
On my machine (SqueakCog, build 15341b5, on Win1903), the magnifier now does not always display the BackgroundMorph but most of the time its background. I can also perceive some flickering, only few frames are rendered correctly. I also tested other ratios, it seems as if the error occurs iff the BackgroundMorph's bounds area (number of pixels) is lower than 2e14. By debugging the number of unique colors in #magnifiedForm|form, I found out that the defect must occur somewhere in Display>>#copy:. Unfortunately, I could not reproduce it by stepping through the code.
As said before, I see that a transparent World color is probably useless, but as I do not understand all relevant code entirely, I thought there could be a more general defect somewhere, beyond this situation.
tldr:
1. The given code piece produces a failure. Should we forbid transparent World colors? 2. Where does this weird 2e14 limit come from? 3. By the way: For testing, I turned the conditional in #magnifiedForm off, in order to always call PasteUpMorph>>#patchAt:without:andNothingAbove:. The comment indicates that Display>>#copy: would be faster, but I could not measure any difference in performance. Is this conditional still needed? The #patchAt:without:andNothingAbove: variant also seems not to be affected by the described rendering issue.
I would be very happy about your reactions :-)
Best, Christoph
The given code piece produces a failure. Should we forbid transparent World colors?
Only if that PasteUpMorph is the project's world. In a not so distant future, we want to revive worlds-in-worlds again. :-)
aWorldMorph == Project current world
For not yet running worlds, this might be a better check:
aWorldMorph owner isNil
Anyway, #isWorldMorph is not sufficient for this issue.
Best, Marcel
P.S.: Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Am 06.09.2019 21:33:45 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi,
should it be a valid state for the World (not an arbitrary PasteUpMorph, but one that #isWorldMorph) to have a transparent TranslucentColor? The current implementation does not forbid this.
I know this would not make much sense, but I discovered a quite interesting rendering problem:
World color: (Color darkGray alpha: 0.2). MagnifierMorph new openInWorld. bg := BackgroundMorph new addMorph: Morph new; position: 200 @ 100; extent: 128 @ 128; "works" openInWorld.
Hover the BackgroundMorph, and the magnifier will work as expected. Now do:
bg extent: 128 @ 127. "fails"
On my machine (SqueakCog, build 15341b5, on Win1903), the magnifier now does not always display the BackgroundMorph but most of the time its background. I can also perceive some flickering, only few frames are rendered correctly. I also tested other ratios, it seems as if the error occurs iff the BackgroundMorph's bounds area (number of pixels) is lower than 2e14. By debugging the number of unique colors in #magnifiedForm|form, I found out that the defect must occur somewhere in Display>>#copy:. Unfortunately, I could not reproduce it by stepping through the code.
As said before, I see that a transparent World color is probably useless, but as I do not understand all relevant code entirely, I thought there could be a more general defect somewhere, beyond this situation. tldr:
* The given code piece produces a failure. Should we forbid transparent World colors? * Where does this weird 2e14 limit come from? * By the way: For testing, I turned the conditional in #magnifiedForm off, in order to always call PasteUpMorph>>#patchAt:without:andNothingAbove:. The comment indicates that Display>>#copy: would be faster, but I could not measure any difference in performance. Is this conditional still needed? The #patchAt:without:andNothingAbove: variant also seems not to be affected by the described rendering issue.
I would be very happy about your reactions :-)
Best, Christoph
Hi,
how would you think about the attached change set?
In a not so distant future, we want to revive worlds-in-worlds again. :-)
Sounds interesting :)
Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Just for interest, what is "World" good for?
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. September 2019 09:09:09 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] TranslucentColor for World: Rendering issue
The given code piece produces a failure. Should we forbid transparent World colors?
Only if that PasteUpMorph is the project's world. In a not so distant future, we want to revive worlds-in-worlds again. :-)
aWorldMorph == Project current world
For not yet running worlds, this might be a better check:
aWorldMorph owner isNil
Anyway, #isWorldMorph is not sufficient for this issue.
Best, Marcel
P.S.: Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Am 06.09.2019 21:33:45 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi,
should it be a valid state for the World (not an arbitrary PasteUpMorph, but one that #isWorldMorph) to have a transparent TranslucentColor? The current implementation does not forbid this.
I know this would not make much sense, but I discovered a quite interesting rendering problem:
World color: (Color darkGray alpha: 0.2). MagnifierMorph new openInWorld. bg := BackgroundMorph new addMorph: Morph new; position: 200 @ 100; extent: 128 @ 128; "works" openInWorld.
Hover the BackgroundMorph, and the magnifier will work as expected. Now do:
bg extent: 128 @ 127. "fails"
On my machine (SqueakCog, build 15341b5, on Win1903), the magnifier now does not always display the BackgroundMorph but most of the time its background. I can also perceive some flickering, only few frames are rendered correctly. I also tested other ratios, it seems as if the error occurs iff the BackgroundMorph's bounds area (number of pixels) is lower than 2e14. By debugging the number of unique colors in #magnifiedForm|form, I found out that the defect must occur somewhere in Display>>#copy:. Unfortunately, I could not reproduce it by stepping through the code.
As said before, I see that a transparent World color is probably useless, but as I do not understand all relevant code entirely, I thought there could be a more general defect somewhere, beyond this situation.
tldr:
1. The given code piece produces a failure. Should we forbid transparent World colors? 2. Where does this weird 2e14 limit come from? 3. By the way: For testing, I turned the conditional in #magnifiedForm off, in order to always call PasteUpMorph>>#patchAt:without:andNothingAbove:. The comment indicates that Display>>#copy: would be faster, but I could not measure any difference in performance. Is this conditional still needed? The #patchAt:without:andNothingAbove: variant also seems not to be affected by the described rendering issue.
I would be very happy about your reactions :-)
Best, Christoph
Just for interest, is this changeset still on your list? :)
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Montag, 9. September 2019 15:01:09 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] TranslucentColor for World: Rendering issue
Hi,
how would you think about the attached change set?
In a not so distant future, we want to revive worlds-in-worlds again. :-)
Sounds interesting :)
Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Just for interest, what is "World" good for?
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. September 2019 09:09:09 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] TranslucentColor for World: Rendering issue
The given code piece produces a failure. Should we forbid transparent World colors?
Only if that PasteUpMorph is the project's world. In a not so distant future, we want to revive worlds-in-worlds again. :-)
aWorldMorph == Project current world
For not yet running worlds, this might be a better check:
aWorldMorph owner isNil
Anyway, #isWorldMorph is not sufficient for this issue.
Best, Marcel
P.S.: Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Am 06.09.2019 21:33:45 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi,
should it be a valid state for the World (not an arbitrary PasteUpMorph, but one that #isWorldMorph) to have a transparent TranslucentColor? The current implementation does not forbid this.
I know this would not make much sense, but I discovered a quite interesting rendering problem:
World color: (Color darkGray alpha: 0.2). MagnifierMorph new openInWorld. bg := BackgroundMorph new addMorph: Morph new; position: 200 @ 100; extent: 128 @ 128; "works" openInWorld.
Hover the BackgroundMorph, and the magnifier will work as expected. Now do:
bg extent: 128 @ 127. "fails"
On my machine (SqueakCog, build 15341b5, on Win1903), the magnifier now does not always display the BackgroundMorph but most of the time its background. I can also perceive some flickering, only few frames are rendered correctly. I also tested other ratios, it seems as if the error occurs iff the BackgroundMorph's bounds area (number of pixels) is lower than 2e14. By debugging the number of unique colors in #magnifiedForm|form, I found out that the defect must occur somewhere in Display>>#copy:. Unfortunately, I could not reproduce it by stepping through the code.
As said before, I see that a transparent World color is probably useless, but as I do not understand all relevant code entirely, I thought there could be a more general defect somewhere, beyond this situation.
tldr:
1. The given code piece produces a failure. Should we forbid transparent World colors? 2. Where does this weird 2e14 limit come from? 3. By the way: For testing, I turned the conditional in #magnifiedForm off, in order to always call PasteUpMorph>>#patchAt:without:andNothingAbove:. The comment indicates that Display>>#copy: would be faster, but I could not measure any difference in performance. Is this conditional still needed? The #patchAt:without:andNothingAbove: variant also seems not to be affected by the described rendering issue.
I would be very happy about your reactions :-)
Best, Christoph
Hi Christoph,
sure. I think that's one to tackle after the 5.3 release. :-)
Best, Marcel Am 07.12.2019 15:21:40 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Just for interest, is this changeset still on your list? :) Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Thiede, Christoph Gesendet: Montag, 9. September 2019 15:01:09 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] TranslucentColor for World: Rendering issue Hi,
how would you think about the attached change set?
In a not so distant future, we want to revive worlds-in-worlds again. :-)
Sounds interesting :)
Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Just for interest, what is "World" good for?
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. September 2019 09:09:09 An: gettimothy via Squeak-dev Betreff: Re: [squeak-dev] TranslucentColor for World: Rendering issue
The given code piece produces a failure. Should we forbid transparent World colors?
Only if that PasteUpMorph is the project's world. In a not so distant future, we want to revive worlds-in-worlds again. :-)
aWorldMorph == Project current world
For not yet running worlds, this might be a better check:
aWorldMorph owner isNil
Anyway, #isWorldMorph is not sufficient for this issue.
Best, Marcel
P.S.: Never use "World". Use "Project current world" if you want to access the project's current world. For worlds-in-worlds, only "ActiveWorld" would return the correct world.
Am 06.09.2019 21:33:45 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi,
should it be a valid state for the World (not an arbitrary PasteUpMorph, but one that #isWorldMorph) to have a transparent TranslucentColor? The current implementation does not forbid this.
I know this would not make much sense, but I discovered a quite interesting rendering problem:
World color: (Color darkGray alpha: 0.2). MagnifierMorph new openInWorld. bg := BackgroundMorph new addMorph: Morph new; position: 200 @ 100; extent: 128 @ 128; "works" openInWorld.
Hover the BackgroundMorph, and the magnifier will work as expected. Now do:
bg extent: 128 @ 127. "fails"
On my machine (SqueakCog, build 15341b5, on Win1903), the magnifier now does not always display the BackgroundMorph but most of the time its background. I can also perceive some flickering, only few frames are rendered correctly. I also tested other ratios, it seems as if the error occurs iff the BackgroundMorph's bounds area (number of pixels) is lower than 2e14. By debugging the number of unique colors in #magnifiedForm|form, I found out that the defect must occur somewhere in Display>>#copy:. Unfortunately, I could not reproduce it by stepping through the code.
As said before, I see that a transparent World color is probably useless, but as I do not understand all relevant code entirely, I thought there could be a more general defect somewhere, beyond this situation. tldr:
* The given code piece produces a failure. Should we forbid transparent World colors? * Where does this weird 2e14 limit come from? * By the way: For testing, I turned the conditional in #magnifiedForm off, in order to always call PasteUpMorph>>#patchAt:without:andNothingAbove:. The comment indicates that Display>>#copy: would be faster, but I could not measure any difference in performance. Is this conditional still needed? The #patchAt:without:andNothingAbove: variant also seems not to be affected by the described rendering issue.
I would be very happy about your reactions :-)
Best, Christoph
Hi Marcel,
I just stumbled upon the same issue again. It would be great if you could review this changeset. :-)
Best, Christoph
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org