World: r3wp

:)

http://rebol.hmkdesign.dk/imagebug.png

It looks like it also has the alpha channel problem.

Try the above image-fit.r program, set it to 2-points and then play 
with the SIZE pair-edit.

that's a very tall window. it doesn't fit on my screen :-)

On XP you see red and yellow stripes in the alpha channel.

Ok, I was thinking of changing that anyway. Hang five.

Ok, reorganised. Try image-fit.r again.

it's difficult to tell. the colors are shifting very quickly, where 
there should only be subtle changes. there are colors that look like 
they shouldn't be there, but I can't be sure.

Do you mean it's harder to see on OSX because of the other colour 
problem ?

yes

colors are bouncing all over the place when I resize it

Ok.

I'll post this later if no one else has any comments.

(The script I was working on which led to this bug was this one:

do read http://anton.wildit.net.au/rebol/gui/demo-future-progress.r

BTW I have fixed the OSX color bug so it could be added in next release.

Anton: the new image color problem you have found is 'by design' 
at the moment ;) The bilinear filter needs image data with premultiplied 
alpha when you want to use image with alpha/transparency. Another 
possibility is to use IMAGE-FILTER NEAREST which doesn't need premultiplied 
alpha in this case. I'll try to think how to solve this 'inconsistency' 
so it doesn't harm performance too much.

Hmm.. that's a bit annoying. Is there really no way the bilinear 
filter can work also on the alpha channel ? That would be a feature 
request to submit to AGG then wouldn't it ?

Good work on the OSX color bug. So now we'll both be able to see 
my bug. :)

Cyphre, so I'll submit a ticket to RAMBO.

Anton, according to the author of AGG the filter calculations would 
be much more complex and thus expensive if done in plain color space. 
Anyway, please submit a ticket to RAMBO I'll try to make the best 
to solve this issue.

Ok, very good.

Ok, submitted bug report to RAMBO.

get-modes s: open tcp://:87 'port-modes crashes new builds.
get-modes c: open tcp://localhost:87 crashes too.  
Probably similar to #3983, as copy get-modes .... works.

REBOL/View 2.7.4.3.1 27-Nov-2006
>> get-modes s: open tcp://:87 'port-modes
== [read write binary lines no-wait direct]

REBOL/View 2.7.4.3.1 27-Nov-2006
Copyright 2000-2006 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM


Licensed to:  .... (commercial) <....>
License ID: ...

Type desktop to start the Viewtop.
>> get-modes s: open tcp://:87 'port-modes


-----------------
Rebol Internal Error: Corrupt datatype: 176 at 201

I have same result as Cyphre. No user.r customizations ?

also - which version of windows is that?

XP Pro
5.1.2600 Service Pack 2 Build 2600
even with empty user.r

the crash does not happen if I read a web page or start e.g. the 
desktop beforehand

>> trace/net on 
crashes Rebol too and wants to send an error report to microsoft

trace/net - i have already reported it to carl.

The crash does not happen, if the license.key is not available.
I submitted it to RAMBO.

interesting. but i have a license.key too.

do you have IE 7?

It's reproducible with more than one installation.

BASE-TEXT/init assumes that font/colors is a series, which means 
that this makes an error:

>> view layout [text "Hello" font svv/vid-styles/FIELD/font]

** Script Error: change expected series argument of type: series 
port
** Where: forever
** Near: change font/colors font/color
if none?

It is the third line where the error occurs.
>> print mold svv/vid-styles/base-text/init
[

    if all [not flag-face? self as-is string? text] [trim/lines text]
    if none? text [text: copy ""]
    change font/colors font/color
...

( and various text styles inherit base-text's INIT )

so... what to do about it ?

Is it the fault of FIELD font not having a colors block, or is it 
the fault of the INIT not being able to handle the NONE case ?

I tend to blame INIT. Patching works well:
	if font/colors [change font/colors font/color]

I had issues with a license key file at one point. I think Cindy 
said things changed, so it could be an issue with a specific license 
key.

it' not my first license.key. I had also problems and got a new key 
some time ago.

i don't have ie 7. so there could be a change to the os that comes 
with ie 7?

hum, I seemed to have stumbled across a pretty mean VIEW bug... it 
seems openeing a popup within an even handler, will send off events 
to TWO feels !!

right now, I have a popup which receives events within its over function 
while the face which called the popup, still receives move (away) 
events within its engage func... funny thing is that I receive a 
steady stream of AWAY actions as I move the mouse!

obviously, since the events are triggered within a different WINDOW! 
  hehe  :-)

this illustrates well how strangely this code reacts:

engage: func [face action event][
	w: find-window face
	probe w/text
	w: find-window event/face
	probe w/text
]

these display different window titles!

anyone know if this has been reported ?

Please post a complete example which shows the buggy behaviour so 
we can check it.