<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Christoph,<div><br></div><div>this looks performance critical. Take a look at BalloonEngine >> #bitBlt:. A color map is slower than computing the target value, according to Tim (tfel).</div><div><br></div><div>This issue is not that critical for the release, is it?</div><div><br></div><div>Btw, you can easily try out different display depth via the world menu:</div><div><br></div><div><img id="4bb30d4b-0cb5-405a-aaad-44b1a9d4af9a" src="cid:d4ac9eaf-b2fc-4dbb-8508-55187e1d4a10" width="auto"></img><br></div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 15.12.2019 12:15:41 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif">
<p>Any chance to fix this bug for 5.3?</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: rgb(0,0,0);font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif;font-size: ;margin: 0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont"></font></div>
</div>
</span></div>
</div>
</div>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">The following would still be a functional workaround:</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><img size="33318" id="x_img117185" tabindex="0" style="max-width:99.9%" src="cid:fd67b6ba-ce69-44a3-94d8-362b808bcc7e"></img><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody"><br>
</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">(</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">Reminder: The bug can be reproduced using</div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div><b>"Example 3"</b></div>
<div><b>f := Form extent: 1 asPoint depth: 16.</b></div>
<div><b>f colorAt: 0 @ 0 put: Color red.</b></div>
<div><b>g := f asFormOfDepth: 32.</b></div>
<div><b>g colorAt: 0 @ 0</b></div>
<div>Expected: Color red</div>
<div>Actual: <span>(Color r: 0.973 g: 0.0 b: 0.0)</span></div>
<div><span>)</span></div>
<div><br>
</div>
<div>Best,</div>
<div>Christoph</div>
</div>
</div>
<div><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Montag, 9. September 2019 16:56:03<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div class="PlainText"><br>
> On 09.09.2019, at 15:53, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> <br>
> Hi Tobias,<br>
> <br>
> oops, I mistook the depth with the number of bits per channel. Sorry and many thanks for your explanations!<br>
> <br>
> How would one fix the upscaling issue? Form>>#colormapIfNeededFor: returns nil in example 3, the comment in Color>>#colorMapIfNeededFrom:to: states this task is delegated to BitBlt. Is this comment wrong or is the defect in the primitive called that is in
BitBlt>>#copyBits?<br>
> <br>
No, that part is only for cross-conversion of Forms and ColorForms<br>
-t<br>
<br>
> Best,<br>
> Christoph<br>
> <br>
> Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
> Gesendet: Montag, 9. September 2019 14:56 Uhr<br>
> An: The general-purpose Squeak developers list<br>
> Betreff: Re: [squeak-dev] Bug in Form>>#asFormOfDepth:?<br>
> <br>
> Hi Christoph,<br>
> <br>
> > On 09.09.2019, at 13:25, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> > <br>
> > Hi all,<br>
> > <br>
> > consider the following example (print it):<br>
> > <br>
> > "Example 1"<br>
> > f := Form extent: 1 asPoint depth: 1.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 2.<br>
> > g colorAt: 0 @ 0<br>
> > <br>
> > Expected output: Color red.<br>
> > Actual output: Color black!<br>
> <br>
> No, Forms of depth 1 are black and white, and of depth2 are gray.<br>
> <br>
> > <br>
> > Other examples:<br>
> > <br>
> > "Example 2"<br>
> > f := Form extent: 1 asPoint depth: 1.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 32.<br>
> > g colorAt: 0 @ 0 "--> (Color r: 0.0 g: 0.0 b: 0.004)"<br>
> <br>
> yes, because you go from black/white to 32bit. I would have expected r0g0b0, but there might some rounding go on.<br>
> <br>
> > <br>
> > "Example 3"<br>
> > f := Form extent: 1 asPoint depth: 16.<br>
> > f colorAt: 0 @ 0 put: Color red.<br>
> > g := f asFormOfDepth: 32.<br>
> > g colorAt: 0 @ 0 "--> (Color r: 0.973 g: 0.0 b: 0.0)"<br>
> <br>
> <br>
> <br>
> Something's wonky here!<br>
> If we do <br>
> <br>
> (((Form extent: 1 asPoint depth: 16)<br>
> colorAt: 0 @ 0 put: Color red)<br>
> asFormOfDepth: 32)<br>
> pixelValueAt: 0@0<br>
> <br>
> we get <br>
> 4294443008 (aka 0xFFF80000) which is a 32bit value.<br>
> But the meaning is <br>
> <br>
> 11111111 11111000 00000000 00000000<br>
> ^ alpha ^ r ^ g ^ b<br>
> <br>
> which means that the r component is not "upscaled" during the #asFormOfDepth: process o.O (see PS)<br>
> <br>
> <br>
> <br>
> <br>
> > <br>
> > I am not familiar with color depths, but afaik Color red could be stored exactly using only 1 bit? Do I misunderstand the concept or is this really a bad output?<br>
> <br>
> No, the first bit depth to support red is 4 bit.<br>
> <br>
> Have a look at Color class>>colorFromPixelValue: p depth: d<br>
> <br>
> BTW: You can use a ColorForm to work with your own palette, so that you can have for example a 1-bit form with 1=yellow & 0=red…<br>
> <br>
> <br>
> Best regards<br>
> -Tobias<br>
> <br>
> > <br>
> > (I came across to this when performing #collectColors: on an 8 bit ColorForm loaded from disk, which did not work as expected.)<br>
> > <br>
> > Best,<br>
> > Christoph<br>
> <br>
> PS: PS:<br>
> Color red is r:1.0 g:0.0 b:0.0 but stored in a different fashion:<br>
> <br>
> Color comment:<br>
> "<br>
> Think of Color's instance variables as:<br>
> r amount of red, a Float between 0.0 and 1.0.<br>
> g amount of green, a Float between 0.0 and 1.0.<br>
> b amount of blue, a Float between 0.0 and 1.0.<br>
> (But, in fact, the three are encoded as values from 0 to 1023 and combined in a single integer, rgb. The user does not need to know this.)<br>
> "<br>
> that means "Color red" is stored as 0x3FF00000 or, <br>
> <br>
> 1111111111 0000000000 0000000000<br>
> ^ red ^ green ^ blue<br>
> <br>
> that makes 10 bit per component.<br>
> <br>
> However, in the 16 bit form we have only 5 bit per component, so, <br>
> <br>
> f := Form extent: 1 asPoint depth: 16.<br>
> f colorAt: 0 @ 0 put: Color red.<br>
> f pixelValueAt: 0@0.<br>
> <br>
> yields 0x7C00 aka<br>
> <br>
> 11111 00000 00000<br>
> ^ r ^ g ^ b<br>
<br>
<br>
<br>
</div>
</span></span>
</div></blockquote></div>