TranslucentColor for World: Rendering issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TranslucentColor for World: Rendering issue

Christoph Thiede

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



Reply | Threaded
Open this post in threaded view
|

Re: TranslucentColor for World: Rendering issue

marcel.taeumel
> 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 <[hidden email]>:

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



Reply | Threaded
Open this post in threaded view
|

Re: TranslucentColor for World: Rendering issue

Christoph Thiede

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 <[hidden email]> 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 <[hidden email]>:

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




translucent worlds.1.cs (5K) Download Attachment