From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Dave MacFarlane Date: Sun, 29 May 2016 20:30:40 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114ac8d0849b930534045f37 Subject: Re: [9fans] More about /dev/draw Topicbox-Message-UUID: 958cf2cc-ead9-11e9-9d60-3106f5b1d025 --001a114ac8d0849b930534045f37 Content-Type: text/plain; charset=UTF-8 Well, that led me down a rabbit hole where I found two problems and now I'm having a third that I need advice on. The main problem was that I was forgot to set the draw op to src when doing the final draw of the window, so it was defaulting to SoverD. Second, unrelatedly, the alpha masks were being doubled (or halved, I guess) when filling an alpha channel because I was using the same id as the src and the mask since they have the same bounds, so the mask was getting multiplied through a second time, but that wasn't affecting the background disappearing since they were opaque colours. Now, after setting the drawop to src, I'm getting a black background instead of a dark blue one. I tried changing the colours arbitrarily to see if black was just how it represents an alpha channel when there's nothing under it, and with lighter colours it's drawing a yellow background on drawterm and a pink one on the Pi. I've narrowed it down to the fact that the the screen channel descriptor on the Pi is different. When I do cat /dev/draw/new, it's telling me it's an r6g5b6 channel while in drawterm it's x8r8g8b8. I'm not sure how that's possible though, because I'm fairly sure I remember reading in a man page that channels had to be multiples of 8, though I can't find where I read that now. Is there anything I can do about this? I'm fairly sure an r6g5b6 channel should be able to represent yellow as a combination of red and green, but the the format of colours in a draw operation is irrespective of the channel format, so I can't be doing anything wrong there. Oddly, the places where I'm directly replacing pixels in the buffer with 'y', where the channel format *does* matter seem to be fine, but I think that might just be luck because the gradient is mostly red and green. On Sun, May 29, 2016 at 8:58 AM, Charles Forsyth wrote: > > On 29 May 2016 at 13:44, Dave MacFarlane wrote: > >> Why would the alpha channel work differently with the same image from the >> same code with the same hardware >> depending on the driver? >> > > Because there might be a difference in the way the components inside the > pixel word are being interpreted or used by memdraw. > -- - Dave --001a114ac8d0849b930534045f37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, that led me down a rabbit hole where I found two pro= blems and now I'm having a third that I need advice on. The main proble= m was that I was forgot to set the draw op to src when doing the final draw= of the window, so it was defaulting to SoverD. Second, unrelatedly, the al= pha masks were being doubled (or halved, I guess) when filling an alpha cha= nnel because I was using the same id as the src and the mask since they hav= e the same bounds, so the mask was getting multiplied through a second time= , but that wasn't affecting the background disappearing since they were= opaque colours.

Now, after setting the drawop to src, I= 'm getting a black background instead of a dark blue one. I tried chang= ing the colours arbitrarily to see if black was just how it represents an a= lpha channel when there's nothing under it, and with lighter colours it= 's drawing a yellow background on drawterm and a pink one on the Pi. I&= #39;ve narrowed it down to the fact that the the screen channel descriptor = on the Pi is different. When I do cat /dev/draw/new, it's telling me it= 's an r6g5b6 channel while in drawterm it's x8r8g8b8. I'm not s= ure how that's possible though, because I'm fairly sure I remember = reading in a man page that channels had to be multiples of 8, though I can&= #39;t find where I read that now.

Is there anythin= g I can do about this? I'm fairly sure an r6g5b6 channel should be able= to represent yellow as a combination of red and green, but the the format = of colours in a draw operation is irrespective of the channel format, so I = can't be doing anything wrong there. Oddly, the places where I'm di= rectly replacing pixels in the buffer with 'y', where the channel f= ormat *does* matter seem to be fine, but I think that might just be luck be= cause the gradient is mostly red and green.

On Sun, May 29, 2016 at 8:58 AM, Char= les Forsyth <charles.forsyth@gmail.com> wrote:

On 29 May 2016 at 13:44, Dave= MacFarlane <driusan@gmail.com> wrote:
Why would the alpha channel work differently= with the same image from the same code with the same hardware
dependin= g on the driver?

Because there mig= ht be a difference in the way the components inside the pixel word are bein= g interpreted or used by memdraw.



--
- Dave
--001a114ac8d0849b930534045f37--