Re:_[9fans]_libdraw_α_differences_between_plan_9__and_p9p

Re:_[9fans]_libdraw_α_differences_between_plan_9__and_p9p

[erik quanstrom]

the answer is i didn't understand that there was a bug in the draw
library; i was not sure if there was a little hidden magic on plan9 that
made that work

- erik

On Fri Mar 31 12:09:26 CST 2006, rsc@swtch.com wrote:
> > i've noticed a difference in how the α channel looks in p9p vs.
> > plan 9. for example when porting mahjongg to plan9port,
> > i need to make this change to make the selection highlighting
> > apparent:
> > 
> > - 	selected = eallocimage(one, 1, RGBA32, setalpha(DPalebluegreen, 0x5f));
> > + 	selected = eallocimage(one, 1, RGBA32, setalpha(DPalebluegreen, 0x9f));
> > 
> > is a mapping needed to convert libdraw α values to X?
> 
> This is the wrong question.  The right question is why you 
> changed this line:
> 
>   	if(level.board[d][x][y].clicked)
> -   		draw(img, r, selected, nil, ZP);
> +   		draw(img, r, selected, selected, ZP);
> 
> Since you're drawing selected through itself, you're effectively
> squaring the alpha, and (0x9F^2)/255 is approximately 0x5F, so
> this change necessitates the first one.
> 
> I see why you changed the draw call, though, since on X, it
> just ignored the alpha channel in selected and just draws
> a big solid-color rectangle over the tile.  This was due to a 
> bug in the X wrappers around libdraw and is now fixed.
> 
> Russ
> 
> P.S. Upas/marshal encodes subjects "correctly" now too.
> 

Re: _[9fans]_libdraw_α_differences_between_plan_9__and_p9p

[andrey mirtchovski]

i hit that bug too when writing mahjongg (in drawterm, not in p9p). i
also didn't understand what was happening and simply did a workaround
(the -c argument, i believe) to force it in 32-bit mode...

you're not alone :)

On 3/31/06, erik quanstrom <quanstro@quanstro.net> wrote:
> the answer is i didn't understand that there was a bug in the draw
> library; i was not sure if there was a little hidden magic on plan9 that
> made that work
>
> - erik

Re: _[9fans]_libdraw_α_differ ences_between_plan_9__and_p9p

[Russ Cox]

>> the answer is i didn't understand that there was a bug in the draw
>> library; i was not sure if there was a little hidden magic on plan9 that
>> made that work

if a function call behaves differently between plan 9 and p9p
for no obvious & documented reason, that's always a bug.

the new drawterm works around this by turning off most of
the X optimizations.  i got tired of working around the early
OS X X server.

russ

Re:__[9fans]_libdraw_α_differ_ences_between_plan_9__and_p9p

[quanstro]

i didn't have plan 9 at the time to compare.

- erik

On Fri Mar 31 16:15:10 CST 2006, rsc@swtch.com wrote:
> >> the answer is i didn't understand that there was a bug in the draw
> >> library; i was not sure if there was a little hidden magic on plan9 that
> >> made that work
>
> if a function call behaves differently between plan 9 and p9p
> for no obvious & documented reason, that's always a bug.
>
> the new drawterm works around this by turning off most of
> the X optimizations.  i got tired of working around the early
> OS X X server.
>
> russ
>

Re:__[9fans]_libdraw_α_differ_ences_between_plan_9__and_p9p

[Charles Forsyth]

> i didn't have plan 9 at the time to compare.

there is no comparison